One of the more frustrating things about running my VNA was taking help desk calls. Not because I had to be on-call evenings and weekends (let’s be honest, no one loves that part) and not when an end-user might need a bit of education. No, the frustration occurred whenever one of my systems was down and I hadn’t known about it. Even worse, when those calls came in it often meant that a doctor or clinician was unable to utilize the system to provide their patients with the highest possible level of care. Which is really why we’re all here, isn’t it, to support optimized patient care?
So, when a ticket did come in the first thing I would try to find out was if the incident involved a single study, was their entire system down, was it isolated to “only” one hospital, or did we have a full network of facilities down? Assuming I could contact the end-user, they were often involved in direct patient care, and unable to stay on the phone with me or the team as we go through the information gathering process. Thus, the troubleshooting procedures would begin, starting with the EMR viewer and image availability, then on to the EMR to see if reports are populating and image links active. Next, the VNA, is it up, are images populating, are they recent or significantly behind? All of this, of course, just being rapid triage, primarily looking for system-wide outages.
I always took it personally when one of my systems (VNA, Enterprise Viewer or Image sharing) was down. It is true that we had active monitoring, as do many facilities, however, that “active monitoring” inevitably turned into a flood of email notifications throughout the day. Many of the emails offering fantastic information about the system; RAM utilization, free drive space, the number of jobs in queue on server 23 etc., etc., etc. But, the incessant ping of noncritical emails eventually becomes deafening and I must admit I, like most of my peers, tuned them out. One issue with most of the systems I was responsible for is that services almost always stay running and the logs rarely filled up the disk drive. This means that many of the purely “IT triggers” that were monitored didn’t turn red, even when a system wasn’t functioning.
The problem is that the monitoring tools we have are not designed to conduct functional testing, nor are they designed around integration testing. Each system is designed to fulfill a role or set of functions. VNA gets studies sent to it but does not know what should be there. An interface engine sends a message and receives and acknowledgment but does not know if it processed. The most insidious of all is the “DICOM error peer aborted association” (or some variant of that language) typically in which, vendor-A enthusiastically determines that vendor-B is the problem. Anyone who has ever been on the phone with two vendors while troubleshooting well knows how this conversation goes … The net result of all of this is that it can take the team hours to determine which system has the problem and then, finally, the concrete problem-solving can begin.
These are only some of the many real-world challenges that made me stop and say, “there must be a better way!” After a recent career change, I was able to put on my thinking cap and build a better way by the name of Heartbeat. Specifically designed to monitor every link in the imaging chain and immediately notify the support team when system A (or B or C) is down. We even let you know when an image doesn’t go from vendor A to vendor B, or if the system is operating so slowly that it may as well be down. Instead of adding to the slew of unread emails Heartbeat notifies your team by the one thing that we’re all plugged into 24 x 7, text messaging. When your PACS or VNA (or any DICOM device) has “fallen and it can’t get up” we make sure you’re alerted within minutes so that your team can be proactive instead of reactive.