LIMS (Laboratory Information Management System) refers to a computerized system that pharmaceutical laboratories use to keep track of and organize test samples, testing tasks, test results, laboratory protocols and records. It is one of the methods through which LIMS validation is done, whereby documented proof is provided to show how appropriate the system is and that it is capable of supporting valid laboratory processes as well as meeting the requirements of GMP.
There are numerous functions that LIMS can perform at a QC laboratory level such as sample registration, analyst assignment, testing, results recording and processing, compliance review as well as report generation. Any malfunction or bad configuration of the system will consequently compromise the laboratory data and quality thereof. It is therefore important that validation is justified in light of the actual use of the system.
The laboratory should keep track of the identification and description of the system's utilization, users, connections, regulated documents, etc. It should also take into account the systems that are interconnected with LIMS, such as Chromatography Data Systems, ERP, balance connections, stability chambers, or instrument data gathering software.
One of the mistakes made while validating the LIMS application is to forget the interfaces and configuration components that affect its outcomes. For instance, it is possible for a LIMS to get the information from an instrument correctly but calibrate the sample ID or test code in the wrong way which will result in the wrong association of the outcome with a certain sample.
The evaluation of purpose gives a ground for a risk-based way of validation. Features that can lead to the product quality problems, laboratory decisions or data reliability are considered during validation.
The requirements may encompass the following:
Each requirement must be marked with a unique identifier and a specific verification method so that it can be traced from the URS to risk assessment, testing process, deviations and the validation report.
For instance, if the format is incorrect, a different risk lies there than in the case of incorrect computation of an assay result. The system may allow unauthorized changes of confirmed results or removal of original data, which may be of great concern to it.
The validation plan has to contain the scope of the system, as well as responsibilities, deliverables, method of testing, as well as criteria of acceptance and the way of handling deviations.
The validation team has to involve the project team members, QA, IT specialists and vendor representatives if needed.
The risk-based approach does not mean that any important functions do not have to be tested. It simply means that the testing will be carried out in the relevant areas.
1. Installation Qualification (IQ) means that basic components of software are set up according to specifications. The coverage will vary according to system topology and may include such elements as software version, server, database components, infrastructure and other documents.
2. Operational Qualification (OQ) implies that functions are tested according to defined functionality specifications. Tests may comprise verification of user rights, sample input, assignment of test to the sample, calculation of the results, presence of specifications, workflow and audit trail documents.
3. Performance Qualification (PQ) is also known as user acceptance testing and shows that a working LIMS is suitable for use in real lab environment. Thus, QC specialist may register a sample, assign tests, enter results and recycle the document.
Positive and negative scenarios should be incorporated in the testing. A test not only must demonstrate that the authorized user can approve the outcome but also validate that the unauthorized user does not approve it.
The documentation and testing conducted by the supplier can be helpful evidence, but the regulated laboratory is responsible for proving that the configuration of the system is correct for its intended purpose. Tests proposed by the supplier have to be evaluated for relevance and applicability with respect to the current configuration of the system.
Access should be assigned according to the roles assumed, which means that analysts, reviewers, administration staff and QA specialists should have rights to access the system. Besides, access to privileged accounts has to be managed in a manner that makes it possible to identify each accountable person.
Audit trails need to include relevant events, related to changes in results, samples, specifications or approvals as well. Verification processes have to ensure that necessary information is captured in the audit trail and that it is safeguarded from wrongful modifications.
Where electronic signatures are being used, they should be subjected to tests to validate their link to the records, the user's identity, the significance attached to the signature and the controls in place. The organization must evaluate relevant legal requirements based on the signatures and records utilized in the course of its business.
Backup and restore tests are equally quite significant. The laboratory should show that important data is recoverable and usable. It should be noted that a successful backup process is not sufficient to assure that the data will be restorable.
For instance, in the case when a LIMS provides the wrong result, a team shall check what formula for calculations has been applied, what rules on rounding were used, what type of measurements, inputs and specification has been considered. The assessment of the impact shall include analysis whether the error affects results or records.
The position taken with respect to CAPA depends on the outcome of assessment made. Retesting shall be scientifically backed up, so that original failed testing has been documented and their results cannot be replaced by newly obtained passing results without providing explanation.
After implementation of the project, any modifications in version of software, configuration, interfaces, business processes, roles of users and IT infrastructure shall be dealt with through the mechanism of change control. Assessment of necessary modifications shall provide an answer to the question whether regression testing, further qualification and revalidation is necessary.
Regular reviews must ensure that the LIMS is still appropriate for its use since the time of its approval. Among other aspects, incident, deviation and auditing practices will have to be evaluated.
The laboratory must also keep updated SOPs and ensure that the personnel is trained for their task ahead of time. The procedures have to provide instructions on the same sample processing, rectification of results and reporting about incidents.
The inspector can ask the lab about how it ensures that LIMS calculation is correct, who has the right to change the reports, how to detect modifications and if the historical information could be obtained. The lab needs to be capable of proving all this using the documentation on LIMS operations.
Define the Intended Use Before Starting Validation
The primary task is defining the intended use of the LIMS as well as identifying which lab processes that are controlled by the system. A LIMS that is utilized only to track samples is going to carry a separate risk compared to the one performing calculations, applying specifications, controlling electronic signatures and interfacing with analytical instruments.The laboratory should keep track of the identification and description of the system's utilization, users, connections, regulated documents, etc. It should also take into account the systems that are interconnected with LIMS, such as Chromatography Data Systems, ERP, balance connections, stability chambers, or instrument data gathering software.
One of the mistakes made while validating the LIMS application is to forget the interfaces and configuration components that affect its outcomes. For instance, it is possible for a LIMS to get the information from an instrument correctly but calibrate the sample ID or test code in the wrong way which will result in the wrong association of the outcome with a certain sample.
The evaluation of purpose gives a ground for a risk-based way of validation. Features that can lead to the product quality problems, laboratory decisions or data reliability are considered during validation.
User Requirements Specification: Establish What Must Work
User Requirements Specification (URS) outlines what the laboratory requires the LIMS to provide. It must be composed in operational terminology and reflect the actual GMP processes.The requirements may encompass the following:
- Individual sample identification and regulated sample registration.
- Distribution of tests according to the approved specifications.
- Recording and computing results and representing them in an acceptable format.
- Review and authorization process that includes authorization level classification.
- Access control for users and permission given according to their duties.
- Audit trail feature, which keeps track of changes in records.
- Electronic signatures, if applicable for the approvals.
- Possessing functions of data backup, restoration and archiving.
- Connections with the devices and computerized systems.
- Dealing with OOS, OOT, invalid tests and retesting according to the procedure.
Each requirement must be marked with a unique identifier and a specific verification method so that it can be traced from the URS to risk assessment, testing process, deviations and the validation report.
Risk Assessment and Validation Planning
Here the risk assessment takes place. The potential impact of failure of a functionality is going to be assessed. This process is aimed at identifying how product quality, laboratory decisions, patients’ safety and data integrity may be affected.For instance, if the format is incorrect, a different risk lies there than in the case of incorrect computation of an assay result. The system may allow unauthorized changes of confirmed results or removal of original data, which may be of great concern to it.
The validation plan has to contain the scope of the system, as well as responsibilities, deliverables, method of testing, as well as criteria of acceptance and the way of handling deviations.
The validation team has to involve the project team members, QA, IT specialists and vendor representatives if needed.
The risk-based approach does not mean that any important functions do not have to be tested. It simply means that the testing will be carried out in the relevant areas.
Qualification and Functional Testing of LIMS
The validation of LIMS typically encompasses documented proof of installation, setup and operation in accordance with specific custom needs of the laboratory. Requirements and definitions for the qualification used should comply with procedures for validation of computerized systems at given site.1. Installation Qualification (IQ) means that basic components of software are set up according to specifications. The coverage will vary according to system topology and may include such elements as software version, server, database components, infrastructure and other documents.
2. Operational Qualification (OQ) implies that functions are tested according to defined functionality specifications. Tests may comprise verification of user rights, sample input, assignment of test to the sample, calculation of the results, presence of specifications, workflow and audit trail documents.
3. Performance Qualification (PQ) is also known as user acceptance testing and shows that a working LIMS is suitable for use in real lab environment. Thus, QC specialist may register a sample, assign tests, enter results and recycle the document.
Positive and negative scenarios should be incorporated in the testing. A test not only must demonstrate that the authorized user can approve the outcome but also validate that the unauthorized user does not approve it.
The documentation and testing conducted by the supplier can be helpful evidence, but the regulated laboratory is responsible for proving that the configuration of the system is correct for its intended purpose. Tests proposed by the supplier have to be evaluated for relevance and applicability with respect to the current configuration of the system.
Data Integrity Controls: Audit Trails, Access and Electronic Records
Data integrity remains a basic concept in LIMS validation process. Any data should be verifiable throughout its whole lifetime including creation, modifications, verification, storage and retrieval.Access should be assigned according to the roles assumed, which means that analysts, reviewers, administration staff and QA specialists should have rights to access the system. Besides, access to privileged accounts has to be managed in a manner that makes it possible to identify each accountable person.
Audit trails need to include relevant events, related to changes in results, samples, specifications or approvals as well. Verification processes have to ensure that necessary information is captured in the audit trail and that it is safeguarded from wrongful modifications.
Where electronic signatures are being used, they should be subjected to tests to validate their link to the records, the user's identity, the significance attached to the signature and the controls in place. The organization must evaluate relevant legal requirements based on the signatures and records utilized in the course of its business.
Backup and restore tests are equally quite significant. The laboratory should show that important data is recoverable and usable. It should be noted that a successful backup process is not sufficient to assure that the data will be restorable.
Managing Validation Deviations and System Changes
All tests that have failed or any unexpected results need to be properly recorded and evaluated. Evaluation shall establish the reason for a problem: whether software defect, fault in configuration, wrong requirements, failure to execute the test, or fault with the data has led to it.For instance, in the case when a LIMS provides the wrong result, a team shall check what formula for calculations has been applied, what rules on rounding were used, what type of measurements, inputs and specification has been considered. The assessment of the impact shall include analysis whether the error affects results or records.
The position taken with respect to CAPA depends on the outcome of assessment made. Retesting shall be scientifically backed up, so that original failed testing has been documented and their results cannot be replaced by newly obtained passing results without providing explanation.
After implementation of the project, any modifications in version of software, configuration, interfaces, business processes, roles of users and IT infrastructure shall be dealt with through the mechanism of change control. Assessment of necessary modifications shall provide an answer to the question whether regression testing, further qualification and revalidation is necessary.
Maintaining the Validated State After Go-Live
The validation does not occur only once an audit has been finalized. The system has to be controlled for its entire life.Regular reviews must ensure that the LIMS is still appropriate for its use since the time of its approval. Among other aspects, incident, deviation and auditing practices will have to be evaluated.
The laboratory must also keep updated SOPs and ensure that the personnel is trained for their task ahead of time. The procedures have to provide instructions on the same sample processing, rectification of results and reporting about incidents.
The inspector can ask the lab about how it ensures that LIMS calculation is correct, who has the right to change the reports, how to detect modifications and if the historical information could be obtained. The lab needs to be capable of proving all this using the documentation on LIMS operations.
Get ready to use editable Validation Protocols in MS-Word FormatView List
No comments:
Post a Comment
Please don't spam. Comments having links would not be published.