I meet with my team every Monday to review issues that occurred over the weekend, repeat service calls for various systems, and any upcoming downtime that we need to notify users about. Our downtime strategy has developed over the last few years from a “let’s at least do it once a year” to a monthly, quarterly, and semiannual schedule to help manage security patching, software bug-fix patching, and regular server and application maintenance. But getting to this point hasn’t been easy.
Many of the systems my team supports are 24×7, and the clinical team never wants them down. So, one of our first steps was communicating the importance of this type of regular maintenance to our clinical customers. Just like preventive maintenance (PM) on a medical device can help lessen the likelihood of a failure, regular patching and maintenance on HTM clinical systems helps lessen the likelihood of an unplanned outage. Additionally, the downtime strategy can help us plan regular intervals for application updates or upgrades.
Managing application updates/upgrades is an important part of the overall life-cycle management for clinical information systems. In the past, it was not uncommon for us to have a clinical system that was several versions behind the current software available from the vendor. When I first started in healthcare technology management (HTM), this wasn’t much of an issue. Systems were generally isolated and updates were only required when you made major system changes (new construction, unit expansion, new organizational needs etc.). Today, the integrated and interoperable nature of clinical systems requires a new approach for support and downtime management.
Developing the downtime rhythm requires consideration of several factors and coordination with multiple groups. Some factors that impact downtime frequency and scheduling include clinical use of the system, internal and external resource availability, and the technical design of the system. Clinical use of the system will identify periods when the system may be inactive or less active. For example, if the endoscopy system is generally used between 6 a.m. and 6 p.m., then a downtime after 7 p.m. and before 5 a.m. would be acceptable. Another important factor to consider is the system design. If the system is capable of high-availability failover, then the downtime for the user is generally negligible or nonexistent so it can be scheduled at the convenience of the technical team.
Coordination with other groups can also impact when downtimes are scheduled. Do you need vendor, server engineering, or database administrator support? Downtimes that require vendor support may need to be scheduled around the normal service support hours for the vendor and coordinated well in advance. You might also need to review the patches with the vendor to confirm there are no conflicts. Additionally, it is important to know what other downtimes are occurring at the same time within the organization. For example, if a downtime of an HTM clinical system requires users to manually document vitals in the electronic medical records (EMR), then it would not be good to schedule the HTM clinical system downtime at the same time as the EMR downtime.
Our HTM downtime strategy was implemented in 2016, but went into full effect in 2017. We support a total of 20 clinical systems and average three individual system downtimes each month. The impact for our team and customers, I believe, has been beneficial. We experienced several emergency and unscheduled downtimes in 2015 and 2016 and have only had one emergency downtime in 2017 so far. Downtime data is used to help evaluate their effectiveness and as a metric for team performance.
Rebecca Arthur is manager of Biomedical Information Systems for the Inova Health System, which serves the Northern Virginia and Washington, DC area. She is a member of AAMI’s Technology Management Council (TMC).