How to do Risk Management of Computer Systems Used for FDA Compliance

Computers are used throughout pharmaceutical research, development, clinical trials and manufacturing. They are used to control equipment and acquire and evaluate data. Data generated by computer systems are used to make decisions whether or not to release drugs into the market and to release batches of finished products for shipment.

Not being able to ship products because of computer failure can have a tremendous impact on a company’s business and a wrong decision to release batches because of wrong quality data can have a severe impact on a patient’s health. Therefore computer systems are amongst the most important targets for risk assessment and control.

Risk and Potential Problems with Computer Systems :

Typical problems with computer systems are:

  • Unclear or wrong requirement specifications. This can cause delays in software development if functions have to be added or updated during development.
  • No vendor qualification/assessment, or vendor qualification is started after the system is
  • Software not validated during development. This can result in additional testing because no evidence of testing may be available from the vendor.
  • No paragraph on support in the purchasing agreement. This can result in reduced uptime because of missing support in case of hardware or software problems.
  • No documentation of installation can result in an FDA observation or warning
  • No testing under high load in the users environment. This can cause unexpected system failures during high system
  • No plan for system back-up. This can result in decreased uptime in the case of a system
  • No plan for data back-up. This can result in loss of data if there is a hard disk

High Level Evaluation and Assessment:

Systems are categorized as high, medium or low risk. The result of this exercise is used to decide if and to what extent Part 11 requirements will be implemented or if it is worth developing and implementing a  detailed risk management plan for a specific process or system. Proposals for such assessments are made by operations and approved by the risk management team.

The resulting risk level information is used for considerations such as:

  • How extensively do we test the computer system? For example, high risk systems will be tested under normal AND high load conditions.
  • How much back-up do we need? For example, for high risk systems we should have validated hardware back-ups for all components. For medium risk systems a back-up of the most critical components is enough and for low risk systems there is no need for back-up.
  • How frequently do we have to back-up data generated by the system?
  • What type of vendor assessment is required? For example, high risk systems will require vendor audits while for medium and low risk a documented experience from the vendor should be enough.
  • What requirements of Part 11 should be implemented in the computer system? For example, for high risk systems computer generated audit trails should be implemented while for low risk systems a paper based manual audit trail is enough.

Factors contributing to high risk computer systems are:

  • Used in regulated applications
  • Used in production environments
  • Used in production quality control environments
  • Product quality problems may permanently impact peoples health.
  • Probability of detecting and correcting errors is low or zero.
  • Must run 24 hours a day, 7 days a week.
  • Highly complex.
  • Highly customized
  • New technology.
  • No support from vendor, e.g., no documented evidence on validation during development, or no phone or on-site support in case of problems.

Factors contributing to low risk systems are:

  • Not used in regulated applications.
  • Used in early product development stage
  • Product quality problems may not have any impact on peoples health.
  • Probability of detecting and correcting errors is high.
  • Used occasionally
  • Widely used commercial systems.
  • No customization
  • Technology bulletproof.
  • Downtime not critical.
  • Support from vendor, e.g., documented evidence on validation during development, local language phone support and/or on-site support in case of problems.

The basic questions to be answered for this assessment are:

  • What is the impact of the computer system on a company’s business and on product quality and how big is the problem if data generated by the system are lost?
  • What is the likelihood that the computer system fails, generates wrong data or loses data?

Below is a sample Checklists which can help to identify risks and activities to control the risk.

Detailed Risk Management:

Related Reading : How to create Risk Management Master Plan For FDA Regulated Companies

Detailed risk management should cover all lifecycle phases. For commercial systems risk factors should be identified for:

  • Setting specifications
  • Selection and qualification of vendors
  • Purchasing
  • Pre-installation
  • Installation
  • Testing
  • On-going use
  • Changes
  • Retirement

A thorough risk management is also very important for software development. For example, most software development projects are not finished in time and don’t have all the desired features. Frequent reasons   are that risks that can possibly delay projects have not been considered. For example, projects are planned under the most optimistic assumptions: there will be no technical problems, nobody from the development team will get sick or leave the company or the department, user requirements will not change during the development phase and finally the number of software bugs will be minimal and do not require extensive bug fixing and re- testing.

For software and computer systems development risks should be identified for:

  • Setting system requirement specifications
  • Definition of design specifications
  • Development of codes
  • Code module and system integrations testing
  • Applications testing
  • Changes and updates
  • Selection and qualification of 3rd parties developing parts of the code

Risk mitigation  and on-going control should follow the recommendations made in the below article under section Risk Mitigation and On-going monitoring review and control :

How to create Risk Management Master Plan For FDA Regulated Companies

Below sample forms can be used for evaluation and mitigation.

Related Articles :

How to Do Risk Assessment of IT Networks for FDA compliance

Risk management of existing(Legacy) systems for FDA Compliance

How to do risk assessment of Spreadsheet and Macros