Data Management Considerations for the Environmental Lab
IT systems need to be under control and part of the quality system

One significant aspect of the environmental lab’s work is to manage its data. Most environmental labs in the U.S. have to follow Environmental Protection Agency (EPA) regulations,1 while in other parts of the world the lab accreditation standard International Organization for Standardization (ISO) 170252 is used. Regardless of which standard is used, even if it is “just” an internal standard, there can’t be faith in the work done without good data management, however well the lab actually works. As most data today is created, calculated, stored and maintained in computer systems, the data management is a matter of handling the computer systems in a good, controlled way.

I recently gave a week-long class on ISO 17025, where I spent a lot of time explaining what the lab needed to do to have control over their computer systems. I was not able to convince one of the participants, who repeatedly said that he worked in a lab and computer systems were just tools. If the computer systems worked, they worked, and if not, he would find someone to fix them. Thus, he was not interested in what to do with the computer systems.

I don’t agree with him: The computer systems are important in any quality lab. You do not necessarily know if the system works or not with your data and your workflow until you have tested and documented that it works as intended. To simplify this statement: We all know that Excel is able to calculate correctly the average of three numbers. Whether the result is correct for our lab or not, depends on whether we have asked Excel to calculate from the correct cells. If we have the wrong cell address, Excel uses the wrong data to do the calculation. The calculation is still perfectly done, but it is not the result in which we are interested.

Unless we have checked that Excel has calculated our data correctly, we can’t really know that it has done so. We can see that there is a result there, but we don’t know if the “system works or not,” to cite my student. Most IT systems in the lab are far more complicated than an Excel calculation of the average of three numbers.

Data Management
The data management that everybody knows about is the backup, which is taken care of by the IT department. This is important for the maintenance of the data, i.e. that we still have the data after it was created and stored, even if the server breaks down.

All labs have methods for their work, whether chemical, electrical, mechanical or other. The lab needs to show that these methods are correctly entered into the IT system so that data is collected, calculated and otherwise handled correctly according to the original method. The IT systems used for this are computerized instruments, laboratory information management systems (LIMS), electronic lab notebooks (ELN), or other systems, including Excel.

LIMS will, in addition, take care of the work processes for each sample or other processes, which usually will have a number of methods attached to the item in question. LIMS also will have information on the instruments’ calibration and maintenance, and of reagents and standards and their expiration dates. A production data system is much like a LIMS, but is tailored for the production processes.

Data management validation for any system includes two major tasks: The first one is to test that the system works within the defined processes in your lab. The second one is to make sure that it is maintained so it will continue to work as intended.

System Testing
System testing is done to check that the system works as intended in your work processes. This can be tested only if you have stated exactly what you expect it to do. Here is where the user requirements specification (URS) comes in. This will state what you want the system to do. Hopefully, this is written before the system is acquired; otherwise, you may not really get the system you need. The URS is important for two reasons: You will clarify for yourself what the lab needs, and you will be able to compare the answers from the various suppliers to see which supplier has the system best fit to your needs.

The system test plan includes test cases set up so that each of the requirements in the URS are tested, including the whole work processes described for your lab. Additionally, there is a need to document the installation of the various hardware and software elements comprising the system. Hardware includes server, clients and network. If this is an instrument system, the instrument itself also needs documentation. Software includes operating system, database, system itself, connecting systems like report generator, etcetera, as appropriate, and the network protocols.

The list may be different for each system. IT systems are usually created by a supplier, and the lab also needs to make sure that the system has been developed in a quality environment. One way of assuring this is to perform a supplier audit. The audit covers the quality system itself, as well as the how the organization develops and tests the system before release.

Once you have thoroughly created all the documentation, tested the system and created the test report, you can, hopefully, say that the system is now validated.

Maintaining the Validated State
It would be good if system testing was all you needed to do to have the system under control. Unfortunately, it is not. The first uncontrolled change takes the system out of its validated state. To prevent this you need procedures/standard operating procedures (SOPs) to make sure that the system is handled in a controlled manner until it retires. How many SOPs are needed depends on factors like how complex the system is and how large you want your SOPs (five pages, 50 pages?). Regardless, there are items that need to be included in SOPs, either in general for all systems in the organization, or for each system:

• error handling, including corrective actions and preventive actions (CAPA)
• change control
• retesting/validation after errors and changes
• configuration management, both external to the system (usually the IT department’s responsibility) and for data in the system (usually the users’ responsibility)
• system description and system logs
• daily use of the system
• entering/changing static data
• qualification of static data
• disaster recovery and business continuity
• organization for the IT system, including who is responsible for what
• risk assessment and risk management
• security and user access
• training: who, how and how much for different user groups
• decommissioning (yes, we need to plan how to decommission or retire our baby)
• backup and retrieval of backup — must also be tested, as it is too late to find out that it does not work when the disaster has struck
• long-term storage of data/archiving, which must be tested just like the backup

Note: This is not a complete list of everything needed in SOPs for every IT system.

Conclusion
In the environmental lab, as in every type of lab where quality is important, the IT systems also need to be under control and to be a part of the lab’s quality system. This brief article is by no means a complete and comprehensive guide to how this should be done. There is literature available to explain in more detail. Scientific Computing has had many good papers on these topics details, and my book International IT Regulations and Compliance has detailed descriptions of how the requirements from various standards shall be fulfilled.

Acronyms 

• CAPA Corrective Actions and Preventive Actions
• ELN Electronic Lab Notebook
• EPA Environmental Protection Agency 
• ISO International Organization for Standardization
• LIMS Laboratory Information Management System
• NELAC National Environmental Laboratory Accreditation Conference
• SOPs Standard Operating Procedures
• URS User Requirements Specification

References
1. EPA regulations include the accreditation standard NELAC (National Environmental Laboratory Accreditation Conference) from 2003
2. ISO 17025:2005 General requirements for the competence of testing and calibration laboratories. www.iso.org

Siri Segalstad is Principal, Segalstad Consulting AS and the author of International IT Regulations and Compliance (Wiley, 2008). She may be reached at editor@ScientificComputing.com.