img

Home > 밸리데이션 > CSV

Edu-talk

이매스교육 및 공지사항

Edu-talk

  • 제목

    LIMS CSV 의 7가지 기본핵심
  • 작성자

    이매스
  • 첨부파일

 
Seven Key Validation Factors for IT Systems in the Lab
Whether part of the instrument, or separate like LIMS and ELN, IT systems are basically handled the same way
By Siri H. Segalstad

Everyone working in a regulatory lab these days knows that everything must be validated. And that “everything” includes analytical methods, instruments and also the IT systems. The IT systems may control the instruments: collect, handle, massage, report or store the data. Non-instrument IT systems also must be validated, including the laboratory information management system (LIMS) and the electronic lab notebook (ELN), as well as spreadsheets, which are so easy to use — and so dangerous from a validation point of view.
The common thread in all validations is that you need the “correct answer” document so that any testing can be compared to these expected results. The document is called the User Requirements Specification (URS), and should be created before the purchase of the instrument or the IT system. Analytical methods validations do not normally have a URS, and the validation instead focuses on precision, detection limits, quantification limits, and range-of-values that can be analyzed with the correct result. Validation of analytical methods is not covered here, and instrument validation has been discussed earlier.1
IT systems, whether they are a part of the instrument, or they are separate like LIMS and ELN, are basically handled the same way. Testing the system is only one of several factors that are included.
1. Validation Plan
First of all, you will need a validation plan, which will define your approach for validation. The validation plan may be in the form of an overall plan for IT systems in general, or specific for this system. It is smart to assess the system for which GAMP5 (Good Automated Manufacturing Practice)2-category system it is. A computerized system is either a category 4 system (defined as “configured software, often very complex, that can be configured by the user to meet the specific needs of the user’s business process”) or a category 5 system (defined as “custom software designed and coded to suit the business processes”). Often, it may be a combination of categories 4 or 5, as some parts are configured standard system, while other parts are customized. GAMP explains what is necessary to be done for each category.
The validation plan will divide the validation into smaller pieces that can be understood and managed. A common approach is the 4Q-method: Development Qualification, Installation Qualification, Operational Qualification, and Process/Performance Qualification. Basically, this is what GAMP4 used, while GAMP5 uses a slightly different terminology, though the core system is the same: You divide the validation into manageable pieces. You may use any division you want to, as long as you define the pieces and stick to the definition while you work. Below, I have used the 4Q approach as an example, but even if you use other ways of dividing the job, you will find useful information here.
The plan does not include the test plans or other details that will be created during the various phases. The validation plan is an overall plan, not a detailed plan!
Validation plan
  • Definition of your phases A, B and C:
    • Required input to each phase, which needs to be fulfilled before the phase starts
    • What shall be done during the phase, e.g. write the test plans, do the testing, and write the report
  • What defines the end of the phase, e.g. testing has been completed, and the report has been authorized
  • Requirements for Procedures to be written and/or changed to accommodate the new/changed IT system
  • Requirement for a validation report as a summary of the validation, i.e. a follow-up on the validation plan
2. Risk Assessment
A risk assessment for the IT systems also is needed. First, assess the risk this system as a whole has on your processes. For an instrument IT system, this depends on how important the results from this system are in the process. Chances are that this is relatively high; otherwise you may not need the instrument. The same is true for a LIMS/ELN system that keeps track of a lot of information for the lab. Even so, there may be parts of the IT system that are not so important and, thus, have a lower risk. When you have assessed which parts are high-risk and which parts are low-risk, you can start understanding where you need to put in a lot of effort for testing and where you can do less.
Mitigation of risks is prioritized as follows:
• Technical mitigation, so that it is done correctly each time instead of left to the operator
• Procedural mitigation, so that the correct way to do the task is described
A new risk assessment needs to be done after mitigation to see how the risks have changed.
Risk assessment
  • The overall risk of the system as it is imbedded in your processes
  • Which risk assessment tool shall be used (there are several, and some may be better suited for your processes and your IT system than others)
  • The risk of parts of the system, using the chosen tool
  • How to mitigate these risks, i.e. make the risks smaller
3. Development Qualification - DQ
The development of the system is partly the supplier’s responsibility and partly yours. The supplier has developed the core system long before you decided to purchase it. You may want to check that this has been done in a manner that you can accept by doing a supplier audit. There, you will check his planning of the system, how he has documented the planning and the decisions, and how he has tested the system.
Your part is the selection processes that lead you to choose this particular system, and your implementation to the supplied system. This needs to be documented as well.
DQ is actually three different parts:
  • Choice of the system, which includes the User Requirements Specification, the answers from the suppliers, and the actual contract between supplier and purchaser
  • Supplier’s development of the system, which can be checked during a supplier audit if desired
  • Implementation of the system, which also includes the procedures for how to implement the various parts of the system
Only when all three have been sufficiently carried out, is the DQ finished.
4. Installation Qualification - IQ
The installation is the smallest and quickest qualification. This is generally done by following an installation script and a quick test that the system has been installed as it should.
IQ
  • The system is installed using an installation script, or it installs itself when you ask it to.
  • Testing is done to see that you can access the system on the server from the various places where you want to access it from either the clients or PCs.
  • Document the installation and the quick testing.
5. Operational Qualification and Process/Performance Qualification
OQ and PQ are defined differently in various companies. This may allow or prevent the phases to be joined together as one phase or kept as two separate phases. Often, OQ is defined as each separate function, and the PQ is defined as how these form the complete process.
When you understand the risks, you can start putting together the plan for testing the system. High-risk items need more testing than lower-risk items. Low-risk items may not need a lot of testing at all. The combination of GAMP category system and risk will tell you where to put your emphasis on the testing.
The major testing effort is in the OQ / PQ phases of the system. This is what we often call the system testing.
OQ-PQ
  • The test plans for system testing are based on the risks and the system category. The test plans use the URS as a “correct answer” document to the testing, i.e. we test that the user requirements are fulfilled in the system.
  • Here, each function (OQ) is tested in the workflow (PQ) where they are to be used. Whether this is done as two separate qualifications or merged into one is up to the user company.
  • The supplier may have done a complete OQ testing of the system before release, and it may be possible to have access to this in order not to have to repeat this testing. However, the PQ testing is obviously needed, as each company has their own unique work processes.
6. Validation report
The validation report sums up all the documents created, and corresponds to the validation plan. If the plan requested that a document was to be created, the report will say that the document was created, and the name and date of the document will be included. Also, the summary results of the tests, along with the pass/fail conclusions, will be included. But, do not repeat everything that has been written before! The validation report is a summary report only, and should give an overview of the validation efforts.
7. Procedures
Somewhere in the validation process, procedures for the IT system also need to be created. Depending on the complexity of the system, this may be one or many procedures. Additionally, other procedures may need to be changed as their work processes describe an old way of doing things, not how to do them using the new system.
Conclusion
This is, of course, not the complete key to validation of IT systems. Scientific Computing frequently has more on the issue. There is also a textbook with a lot more detailed information than a short article can cover.3 This textbook is used in university graduate courses.
References
1. Segalstad: Instrument qualification, Scientific Computing. July 2009.
2. GAMP 5 Good Automated Manufacturing Practice (GAMP) Guide for A Risk-Based Approach to Compliant GxP Computerized Systems, February 2008, International Society for Pharmaceutical Engineering (ISPE), Fifth Edition, ISBN 1-931879-61-3,
www.ispe.org.
3. Segalstad: International IT Regulations and Compliance, Book 344 pages, ISBN 978-0-470-75882-3, Wiley-Blackwell, October 2008
.
Siri Segalstad is Principal, Segalstad Consulting AS and the author of International IT Regulations and Compliance (Wiley-Blackwell, 2008). She may be reached at editor@ScientificComputing.com.
Acronyms
 DQ Development Qualification  ELN Electronic Laboratory Notebook  GAMP Good Automated Manufacturing Practice  IQ Installation Qualification
 LIMS Laboratory Information Management System  OQ Operational Qualification  PQ Process/Performance Qualification  URS User Requirements Specification