Introduction
This guidance explains how Component Level Impact Assessment can be performed for Information System Applications.
This document only applies to Information Systems and it does not apply to any Process Control systems.
The classification of Information System components as critical or non critical can be performed using a Component Level Impact Assessment in order to determine which components need
qualification. This guidance also gives guidance on how to identify components in applications and includes examples of component level impact assessments for three typical software applications.
Recommendations & Rationale
In the absence of a component level impact assessment, all components of new direct impact systems must be considered as critical components and need to be qualified. However, if there is a documented rationale based on a Component Level Impact Assessment, components might be classified as non-critical based on their lack of potential to impact product quality or regulatory
Compliance Practices.
It is recommended to base the component level impact assessment on the specifications that define the functions of the system (e.g., Functional Requirement Specification) or other
document(s) describing the system functionalities. An application profile (system description addressing the key functionality and how the functionality is used) may also be used to provide
unambiguous information that is needed to answer the CLIA questions and to provide supporting rationale.
The Component Level Impact Assessment templates should be created to list a set of questions used to determine whether the component/function is critical or not. Typically, the only question that directly applies to Information Systems is the following question:
Does the component produce, monitor, evaluate, store or report Critical data1?
This question will be answered yes if:
* The component/function is used to print primary2 records and/or signatures that are required by regulation (predicate rules);
Examples:
The component/function generates, stores or transmits training records, calibration records, change control records, deviation resolution records, batch records, laboratory data, validation documentation, annual product reviews, cleaning records, and GMP documents (e.g., SOPs).
The component/function manages records that support the process of annual reviews or batch yield calculations.
The component/function manages data that are used to create labels that identify a drug substance, intermediate, commercial product, clinical material or drug product.
The component/function manages data that are part of the batch record or used to support lot release.
The component/function generates, stores or transmits data used to support quality decisions related to product quality;
Examples:
The component/function is used for evaluation of acceptance/rejection of raw materials, in-process materials or final products (e.g. laboratory test result values).
The component/function is used in demonstrating compliance with a registered process. The term “registered process” refers to documents filed with regulatory agencies (e.g. an artwork system storing the sizes and colors of packaging material).
The system generates, stores or transmits product status (e.g. released versus quarantined).
Definition:
Critical Data are defined as data that are used to accept or reject product or material, to support decisions related to product quality, or to support Regulatory Compliance Practices.
The term “primary” record is used to exclude systems that are used to create a paper document, where the paper document is the primary document
Critical Components
A Critical Component can be defined as a physical element or function of a system where operations, contact, data, control, alarm or failure directly impacts product quality or regulatory compliance.
A non-critical component is defined as a physical element or function of a system where the operation, contact, data, control, alarm, or failure will have no impact on product quality or regulatory compliance practices.
For Information Systems, critical and non-critical components are best categorized as critical and non-critical functions. A critical function can be defined as any of the following:
- A function within a direct impact system used to support the manufacturing, processing, packaging, labeling, testing, holding or distribution of a material or product, that has a direct impact on a product’s safety, identity, strength, quality, purity, status or traceability; or
- A function within a direct impact system used to support the manufacturing, processing, packaging, labeling, testing, holding or distribution of a material or product, that has a direct impact on regulatory compliance practices.
If a system has one or more critical functions then it is, by definition, a Direct Impact System. Direct Impact Systems manage Critical Data. Only Direct Impact Systems can have critical components. The CLIA should only assess functions that manage Critical Data.
Additional CLIA questions for IS systems:
However, not all functions that manage Critical Data are critical. The following three questions which supplement the above question may help in determining whether the function is critical. If
one of the following questions is answered yes, the component is considered to be a critical component and must be qualified.
1. Does the function impact the accuracy and reliability of Critical Data?
Examples:
- A function that generates data
- A function that stores data
- A function that processes data
- A function that manipulates data (calculations)
- A function that outputs data
2. Does the function impact the authenticity and integrity of Critical Data?
Examples:
- A function that protects Critical Data from unauthorized modification
- A function that controls the migration or transfer of Critical Data
3. Does the function impact the availability of Critical Data?
Examples:
- A function that archives data
- A function that backs up data
- A function that retrieves data
Approaches
The following flowchart depicts the approaches to follow to perform the Component Level Impact Assessment (CLIA).
Identification of Components
One of the challenges in performing Component Level Impact Assessment is identifying individual components (functions) in software products. An approach for identifying components includes identifying each (numbered) Specification item (e.g. Functional Specification) as a component.
Example for a LIMS system (Note: This is just an example only. Not all the functions within a LIMS system are listed below):
| Component (Function) | Critical | Rationale | |
| 1) | Certificate of analysis (CoA) report functionality | Y | C of A report functionality outputs Critical Data. |
| 2) | Sample analysis report functionality | Y | Sample analysis report functionality outputs Critical Data (used to accept/reject product) |
| 3) | Stability summary report functionality | Y | Stability summary report functionality outputs Critical Data that support regulatory compliance practices |
| 4) | Sample creation functionality | Y | Sample creation functionality generates Critical Data. The sample creation functionality may involve assigning tests linked to sample identity. |
| 5) | Support Multiple Language functionality | N | Multiple Language functionality doesn’t affect Critical Data. |
| 6) | Define estimated testing time at the product, sample or individual test level. | N | Defining Estimated testing time does not affect Critical Data. |
| 7) | Sample approval functions | Y | Sample approval functionality generates Critical Data that support regulatory compliance practices |
| 8) | Email Notification of Test Failure | N | Email Notification is not required by regulatory compliance practices |
| The assessment above results in the conclusion that functions 1), 2), 3), 4) and 7) need to be commissioned and qualified, while functions 5), 6) and 8) only require commissioning. | |||
Example for an ERP System (Note: This is just an example only. Not all the functions within an ERP system are listed below): Component (Function) Critical Rationale
| Component (Function) | Critical | Rationale | |
| 1) | Create a quote for an approved item / vendor relationship | N | This functionality does not affect Critical Data. |
| 2) | Maintain quote delivery dates | N | This functionality does not affect Critical Data. |
| 3) | Maintain price and discount breaks for a quote | N | This functionality does not affect Critical Data. |
| 4) | Create a contract for approved item / vendor | N | This functionality does not affect Critical Data. |
| 5) | Delete sales forecast | N | This functionality does not affect Critical Data. |
| 6) | Require confirmation prior to deletion of a Master Manufacturing Phase. | N | This functionality does not affect Critical Data. |
| 7) | Allow user to make changes to customer records | N | This functionality does not affect Critical Data. |
| 8) | Create production plan | Y | This functionality generates Critical Data. |
| 9) | Create new lot numbers for each production order | Y | This functionality generates Critical Data. |
| 10) | The system will require a user to change their password after a pre defined period of time. | Y | This functionality protects Critical Data from unauthorized medication. |
| 11) | System will record a history for a production plan | Y | This functionality ensures authenticity of Critical Data. |
| 12) | Print a production plan | Y | This functionality outputs Critical Data. |
| The assessment above results in the conclusion that functions 1) to 7) need to be commissioned, while functions 8) to 12) require commissioning and qualification. | |||
Example for a Training System (Note: This is just an example only. Not all the functions within a Training system are listed below): Component (Function) Critical Rationale
| Component (Function) | Critical | Rationale | |
| 1) | The training module will be identified by a unique module identifier, title and date. | N | This functionality does not affect Critical
Data. |
| 2) | The training module identifier will include a revision code. | N | This functionality does not affect Critical Data. |
| 3) | The training module must be accessible on company’s Intranet. | N | This functionality does not affect Critical Data. |
| 4) | The training module must be able to support multiple simultaneous users. | N | This functionality does not affect Critical Data. |
| 5) | System access is limited to authorized individuals. | Y | This functionality protects Critical Data from unauthorized medication. |
| 6) | The training module will automatically print the “Laboratory Analyst Training Record” report for users who passed the Test. | Y | This functionality outputs Critical Data. |
| The assessment above results in the conclusion that functions 1) to 4) need to be commissioned, while functions 5) to 6) require commissioning and qualification. | |||