Efficient monitoring system alarm testing: A hybrid approach

We often receive questions from professionals in life science on best practices for creating and managing GxP environments. In this blog we share a recent question from a technician installing the viewLinc Continuous Monitoring System.  

Question:  I am a contract validation specialist working with a global pharmaceutical manufacturer. Right now, I am implementing the Vaisala viewLinc CMS into a new warehouse and currently planning to test viewLinc’s alarm functions.  As I understand, to test the threshold alarm settings, the viewLinc system does not allow for a user to "force" or simulate an analog input value. My question is—is it possible to configure the data loggers to a loop calibrator to force the input values? Thank you for your help!

Answer: I appreciate your challenge and am also happy to see alarm testing being done.  Not everyone does it, but it’s critical to test alarms periodically.   As a validation professional, I don’t necessarily think alarms are GMP as release criteria are usually based on actual temperatures rather than the presence or absence of alarms.  

However, alarms are relied upon to protect significant product assets, and are one of the main reasons why customers use automated monitoring systems.

I only mention this distinction (which may not be an actual difference) in case it helps in your scenario to treat alarm functions as a business risk and not a GMP risk.  Having said that, I don’t know if I would want to defend that distinction under audit.  I would strongly caution you against trying to force input values on any Vaisala logger.  They are not designed for that purpose, and it may damage the data logger.  

Instead, I offer two options:  

Choice 1: Use DL1416 (or another external probe data logger) and put the external probe in a dry well calibration bath. Use that setup to create your alarm temperature.  The advantage here is that you can test the threshold at the exact configured value.  The downside is the complexity and bother of the bath system.

Choice 2: Manipulate the thresholds settings directly.  If you need to prove that the HIGH threshold alarm on Logger X works, edit the threshold to place the threshold value below the current value.  This will trigger the alarm cascade and any associated notifications.  The advantage here is that you can test the threshold without any calibration equipment or simulators, etc.  The downside is that the alarm is being tested at an arbitrary value, NOT an exact configured value.  

I prefer Choice 2 myself, as I think it is an easy argument to state that even through the high threshold was set at 8C, and my high alarm test was done at an arbitrary value (for example 5°C), I can still state that the high alarm was generated, and the notification cascade functioned. And I have verified that the high threshold is correctly configured at 8°C.  So, the only risk is that for some unknown reason or hidden code error… the alarm won’t function at 8°C but works at 5°C. I consider this a minimal risk. 

A Hybrid Approach to Alarm Testing

My full recommendation for alarm testing is a hybrid approach that leverages other things we know about the system, specifically that we have calibrated sensors AND that the thresholds are all based on templates.

1)    Test a single location in a way the shows that the alarm goes off at the intended value.  This is quite easy, do it for a refrigerator with an 8°C alarm and just open the refrigerator door to raise the temperature.  Verify that the alarm is generated when the actual temperature values cross the intended threshold.  This establishes that the system will generate an alarm when an actual value passes and actual threshold.  You could also do this using the Choice 1 calibration bath approach.  But only do it for a single logger (or three if your client needs verification in triplicate).  But DON’T do it for every logger and every threshold.

2)    Verify that all data loggers with programmed thresholds are calibrated.  This establishes that the values coming into the system for alarming are correct.  Seems silly, but there are people who structure alarm tests in a way that turn the alarm test into nothing other than a poor double-check of the calibration with added uncertainty.

3)    Test all other alarm templates by the Choice 2 method, by adjusting the alarm threshold to trigger the alarm.  Do not test every data logger.  Only do this test once per THRESHOLD per THRESHOLD TEMPLATE (or per NOTIFICATION TEMPLATE).  If the system is configured efficiently, using templates for alarming, then you will have to actually test far fewer alarms.

So, the basic idea of leveraging templates is that you test each template ONCE, and then for each data logger or location, verify that the correct template (which you just tested) is in use.

I hope this is helpful! There are many guides and technical guidance for viewLinc in our Document Portal and we are here to help. Check out the Vaisala Support Portal.