Computerized system validation

Last updated

Computerized system validation (CSV) (Computerised system validation in European countries, and usually referred to as "Computer Systems Validation") is the process of testing/validating/qualifying a regulated (e.g., US FDA 21 CFR Part 11 [1] ) computerized system to ensure that it does exactly what it is designed to do in a consistent and reproducible manner that is as safe, secure and reliable as paper-based records. This is widely used in the Pharmaceutical, Life Sciences and BioTech industries and is a cousin of Software Testing but with a more formal and documented approach. The validation process begins with validation planning, system requirements definition, testing and verification activities, and validation reporting. The system lifecycle then enters the operational phase and continues until system retirement and retention of system data based on regulatory rules.

Contents

Similarly, The Rules Governing Medicinal Products in the European Union, Volume 4, Annex 11: Computerised Systems applies to all forms of computerized systems used as part of a GMP regulated activities and defines Computer System Validation Elements [2]

System requirement

Documented system requirements are required for CSV as they clearly stipulate the intended use of a computer system application. System requirements are gathered and documented in the system definition phase. System definition artifacts that reflect these requirements can include, but are not limited to, the following:

See also

Related Research Articles

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

Avionics software is embedded software with legally mandated safety and reliability concerns used in avionics. The main difference between avionic software and conventional embedded software is that the development process is required by law and is optimized for safety. It is claimed that the process described below is only slightly slower and more costly than the normal ad hoc processes used for commercial software. Since most software fails because of mistakes, eliminating the mistakes at the earliest possible step is also a relatively inexpensive and reliable way to produce software. In some projects however, mistakes in the specifications may not be detected until deployment. At that point, they can be very expensive to fix.

Medical software is any software item or system used within a medical context, such as reducing the paperwork, tracking patient activity

In engineering, a requirement is a condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear and often quantitative description of a condition to be satisfied by a material, design, product, or service.

Structured systems analysis and design method (SSADM) is a systems approach to the analysis and design of information systems. SSADM was produced for the Central Computer and Telecommunications Agency, a UK government office concerned with the use of technology in government, from 1980 onwards.

<span class="mw-page-title-main">Good manufacturing practice</span> Manufacturing quality standards

Current good manufacturing practices (cGMP) are those conforming to the guidelines recommended by relevant agencies. Those agencies control the authorization and licensing of the manufacture and sale of food and beverages, cosmetics, pharmaceutical products, dietary supplements, and medical devices. These guidelines provide minimum requirements that a manufacturer must meet to assure that their products are consistently high in quality, from batch to batch, for their intended use.

In software project management, software testing, and software engineering, verification and validation is the process of checking that a software engineer system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

The Federal Information Processing Standard Publication 140-2,, is a U.S. government computer security standard used to approve cryptographic modules. The title is Security Requirements for Cryptographic Modules. Initial publication was on May 25, 2001, and was last updated December 3, 2002.

<span class="mw-page-title-main">V-model</span> Graphic of a systems development lifecycle

The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models. The V-model falls into three broad categories, the German V-Modell, a general testing model, and the US government standard.

<span class="mw-page-title-main">Medical device</span> Device to be used for medical purposes

A medical device is any device intended to be used for medical purposes. Significant potential for hazards are inherent when using a device for medical purposes and thus medical devices must be proved safe and effective with reasonable assurance before regulating governments allow marketing of the device in their country. As a general rule, as the associated risk of the device increases the amount of testing required to establish safety and efficacy also increases. Further, as associated risk increases the potential benefit to the patient must also increase.

The 140 series of Federal Information Processing Standards (FIPS) are U.S. government computer security standards that specify requirements for cryptographic modules.

A test plan is a document detailing the objectives, resources, and processes for a specific test session for a software or hardware product. The plan typically contains a detailed understanding of the eventual workflow.

The process of establishing documentary evidence demonstrating that a procedure, process, or activity carried out in testing and then production maintains the desired level of compliance at all stages. In the pharmaceutical industry, it is very important that in addition to final testing and compliance of products, it is also assured that the process will consistently produce the expected results. The desired results are established in terms of specifications for outcome of the process. Qualification of systems and equipment is therefore a part of the process of validation. Validation is a requirement of food, drug and pharmaceutical regulating agencies such as the US FDA and their good manufacturing practices guidelines. Since a wide variety of procedures, processes, and activities need to be validated, the field of validation is divided into a number of subsections including the following:

Title 21 CFR Part 11 is the part of Title 21 of the Code of Federal Regulations that establishes the United States Food and Drug Administration (FDA) regulations on electronic records and electronic signatures (ERES). Part 11, as it is commonly called, defines the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records.

Verification and validation are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. These are critical components of a quality management system such as ISO 9000. The words "verification" and "validation" are sometimes preceded with "independent", indicating that the verification and validation is to be performed by a disinterested third party. "Independent verification and validation" can be abbreviated as "IV&V".

A specification often refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.

Software requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:

  1. A condition or capability needed by a user to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
  3. A documented representation of a condition or capability as in 1 or 2

Good documentation practice is a term in the pharmaceutical and medical device industries to describe standards by which documents are created and maintained. While some GDocP standards are codified by various competent authorities, others are not but are considered cGMP. Some competent authorities release or adopt guidelines, and they may include non-codified GDocP expectations. While not law, authorities will inspect against these guidelines and cGMP expectations in addition to the legal requirements and make comments or observations if departures are seen. In the past years, the application of GDocP is also expanding to cosmetic industry, excipient and ingredient manufacturers.

ISO 26262, titled "Road vehicles – Functional safety", is an international standard for functional safety of electrical and/or electronic systems that are installed in serial production road vehicles, defined by the International Organization for Standardization (ISO) in 2011, and revised in 2018.

Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. It is applied in the context of agile software development methods, in particular behavior-driven development. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organisational complexity.

References

  1. Commissioner, Office of the (2020-06-11). "Part 11, Electronic Records; Electronic Signatures - Scope and Application". U.S. Food and Drug Administration. Retrieved 2021-09-10.
  2. EUROPEAN COMMISSION (2011-06-30). "EudraLex, The Rules Governing Medicinal Products in the European Union Volume 4, Good Manufacturing Practice Medicinal Products for Human and Veterinary Use, Annex 11: Computerised Systems" (PDF). European Commission. Retrieved 2023-03-11.