Getting Compliant & Staying There: Part II - Change Control for Environmental Monitoring Systems Paul Daniel, Vaisala Senior GxP Regulatory Compliance Expert Published: Jun 13, 2013 Life Science This week, our Senior Regulatory Expert Paul Daniel addresses a question he received by email on documenting changes to a continuous monitoring system Don't forget to check out our other webinars. Please find other Validation Resources and Articles on GxP here. Learn more about the Vaisala's Validation system. If you need further assistance, contact us.
Hi Paul, When making any changes to the CMS Server, such as adding more storage, should we amend the validation records to state that storage space has been added to the physical server, or do we have to perform a completely new IQOQ on that server? We are going to be doing an internal audit to prepare for an actual FDA audit and we need all our ducks in a row... Your input is much appreciated and looked forward to. Warm Regards, J Paul answers Hi J, Thanks for emailing. In any situation, preparing for both an in-house audit or an FDA inspection, I would always follow the internal change control procedures that your IT department has for network systems as well as the GMP Change Control SOP that your Quality department has for validated systems. It's likely that the change will be evaluated by the system expert (you), and a change control form will be filled out with any proposed testing, then the change evaluated by a committee. Once the change is implemented and the testing carried out, the change is reviewed afterwards. Within this framework, you might wonder, how much testing is required? Good question! I think this will depend on how you are adding storage to the server. There are probably three ways to add storage: Add a physical hard drive to a server that is used for storage only by the physical viewLinc server through a mapped drive. Add memory allocation to a virtual server. Add a physical hard drive directly to a physical viewLinc server. Any of the above change should be documented, at a bare minimum, with a memo to the system file and the validation file. But what needs to be tested? In this case, I would do the following: Verify a recent backup exists. Do a sample report for one channel (or a few channels) for a month. Shut down the CMS server. Add storage/memory. Start up the CMS Server and verify the CMS application is running. Login to the CMS. Repeat the same sample report generated in Step 2. Compare reports to make sure they are identical. You will need to write a brief protocol for this, but these tests are quite simple so they should be easy to write. You can likely just edit a copy of IQOQ used to for the initial qualification of your Continuous Monitoring System. The key parts for any change to a CMS are: Document the change or additions, and After the change, verify the following: a. Application is running. b. Login is successful. c. Reporting is functional. Compare before and after reports. d. Alarming is functional. Run an alarm test. Basically, most modern “Off-the-Shelf” or “Configurable” applications are not affected by changes in the operating environment such as the addition of memory. However it is a risk anytime the server is touched. So after the upgrade, we just want to do a few basic tests to make sure no critical functions were affected. This rationale, however, may not apply to a custom programmed system. I hope that helps! Best regards, Paul Daniel Sr. Regulatory Compliance Expert Life Science Vaisala Inc
Paul answers Hi J, Thanks for emailing. In any situation, preparing for both an in-house audit or an FDA inspection, I would always follow the internal change control procedures that your IT department has for network systems as well as the GMP Change Control SOP that your Quality department has for validated systems. It's likely that the change will be evaluated by the system expert (you), and a change control form will be filled out with any proposed testing, then the change evaluated by a committee. Once the change is implemented and the testing carried out, the change is reviewed afterwards. Within this framework, you might wonder, how much testing is required? Good question! I think this will depend on how you are adding storage to the server. There are probably three ways to add storage: Add a physical hard drive to a server that is used for storage only by the physical viewLinc server through a mapped drive. Add memory allocation to a virtual server. Add a physical hard drive directly to a physical viewLinc server. Any of the above change should be documented, at a bare minimum, with a memo to the system file and the validation file. But what needs to be tested? In this case, I would do the following: Verify a recent backup exists. Do a sample report for one channel (or a few channels) for a month. Shut down the CMS server. Add storage/memory. Start up the CMS Server and verify the CMS application is running. Login to the CMS. Repeat the same sample report generated in Step 2. Compare reports to make sure they are identical. You will need to write a brief protocol for this, but these tests are quite simple so they should be easy to write. You can likely just edit a copy of IQOQ used to for the initial qualification of your Continuous Monitoring System. The key parts for any change to a CMS are: Document the change or additions, and After the change, verify the following: a. Application is running. b. Login is successful. c. Reporting is functional. Compare before and after reports. d. Alarming is functional. Run an alarm test. Basically, most modern “Off-the-Shelf” or “Configurable” applications are not affected by changes in the operating environment such as the addition of memory. However it is a risk anytime the server is touched. So after the upgrade, we just want to do a few basic tests to make sure no critical functions were affected. This rationale, however, may not apply to a custom programmed system. I hope that helps! Best regards, Paul Daniel Sr. Regulatory Compliance Expert Life Science Vaisala Inc
Paul Daniel, Vaisala Senior GxP Regulatory Compliance Expert Paul Daniel has worked in the GMP-regulated industries for over 25 years helping manufacturers apply good manufacturing practices in a wide range of qualification projects. His specialties include mapping, monitoring, and computerized systems. At Vaisala, Paul oversees and guides the validation program for the Vaisala viewLinc environmental monitoring system. He serves as a customer advocate to ensure the viewLinc environmental monitoring system matches the demanding requirements of life science and regulated applications. Paul is a graduate of University of California, Berkeley, with a bachelor’s degree in biology. Connect on LinkedIn
Paul Daniel, Vaisala Senior GxP Regulatory Compliance Expert Paul Daniel has worked in the GMP-regulated industries for over 25 years helping manufacturers apply good manufacturing practices in a wide range of qualification projects. His specialties include mapping, monitoring, and computerized systems. At Vaisala, Paul oversees and guides the validation program for the Vaisala viewLinc environmental monitoring system. He serves as a customer advocate to ensure the viewLinc environmental monitoring system matches the demanding requirements of life science and regulated applications. Paul is a graduate of University of California, Berkeley, with a bachelor’s degree in biology. Connect on LinkedIn
