Many hospitals strive to implement systems that allow for timely and reliable communication of critical laboratory results (CLRs) to the responsible physician.1–3 With recent advances in health information technology (IT), an increasing number of institutions are turning to solutions that involve varying degrees of automation to streamline this process. The use of automation to improve the efficiency and reliability of an alerting process is enticing. Many of us have benefited from automation in our day-to-day lives: Reminders in our calendars, alerts sent to our smartphones indicating our flight is delayed, or monthly withdrawals from our bank accounts to pay our bills are just a few examples. When thoughtfully designed and applied, automation can make life both more simple and reliable.

However, there is a common misconception that automation is as simple as flipping a switch that, when activated, replaces unpredictable human activity with a foolproof system that delivers the same result every time. Unfortunately, an automated solution often fails to achieve its desired outcome, in large part because the underlying process being automated has not been carefully considered.

Rushing to introduce automation without careful planning to account for existing clinical processes is the Achilles' heel of any health IT implementation. A study of computerised provider order entry (CPOE) implementation in a paediatric intensive care unit (ICU) that purportedly increased mortality offers a sobering example of the potential risks of premature implementation.4 Before CPOE implementation, when a child was transferred from an outside institution to their ICU, the paediatric intensivist would order medication infusions so that they could be prepared in advance, arrange for diagnostic imaging studies to be carried out immediately on arrival, and write the admission orders, all before the patient arrived. However, after CPOE implementation, none of these anticipatory actions could take place because the system would not permit these orders to be processed until the patient physically arrived into the ICU and was registered in the system. Although eventually rectified, this new constraint imposed by their CPOE implementation did not align with existing clinical workflow processes and led to important delays that may have contributed to the increased mortality rate in their ICU post-CPOE implementation.

Prior attempts at automating CLR alerting to physicians have been met with variable success, due in part to similar implementation challenges. We recently introduced an automated CLR alerting protocol paired with clinical decision support in our home institution.2 ,5 However, we were not successful because we failed to address important gaps in the process prior to automation. The existing physician paging process was haphazard at best, and was not linked to the physician call schedule. This made it difficult for us to deliver automated alerts to the responsible physicians reliably. Furthermore, the web-link to the clinical decision support was sent with the CLR alert to the physicians' text pagers. This required the added step of finding a computer to access the decision support, which significantly limited its use.

In this week's issue, Ti and colleagues published a report describing the end-to-end redesign of their CLR reporting pathway that combines the use of automation with manual backup telephone alerting.6 Their solution automatically sends a CLR alert to the ordering physician's smartphone, and escalates the CLR to a covering physician if the original alert is not acknowledged. If no physician acknowledges the CLR via the automated pathway, there is a manual backup telephone CLR alerting pathway that notifies a physician on call that is known to be available. Over a period of 4 years, they were able to achieve a significantly faster acknowledgement time of CLRs, as well as improve the provider response time to act or intervene on them.

In designing their automated alerting pathway, they paid close attention to the underlying process of alerting a physician, which allowed them to incorporate important features of an effective and reliable automated CLR system.7 First, their process clearly designated the ordering physician to receive the initial alert, a decision that allowed for a common procedure for both inpatient and outpatient CLRs. Second, their escalation protocol is linked to the physician call schedule and automatically alerts physicians who are on duty and able to receive the CLR (and therefore more likely to acknowledge it). They specifically engaged front-line physicians in each department to tailor the individual escalation strategies to their workflow and schedules. Third, their process activates a fail-safe backup mechanism if a CLR alert sent via the automated pathway is not acknowledged. In these instances, their process defaulted to the pre-existing manual telephone-alerting pathway. The research team's careful consideration of these scheduling and communication processes significantly enhanced the success of their intervention.

However, on closer examination, their study findings suggest that the direct impact of automating the CLR alerting process cannot fully account for the observed benefit. Half of the CLRs sent to physicians via the automated pathway were not acknowledged and triggered the manual backup system. In fact, the intervention time for CLRs post automation was only slightly faster for the automated pathway as compared to the manual backup pathway (16 min vs 23 min respectively); both were dramatically faster than the pre-implementation time to intervention of 109 min. This suggests that there may be unintended effects of automation that indirectly contributed to improving the CLR alerting process.

Unintended consequences of health IT have been well documented. Many reports have focused on the unintended risks that new health IT introduces, such as CPOE facilitating medication ordering on the wrong patient,8 or electronic medical records propagating copy and paste errors.9 However, new technology can also lead to unanticipated benefits that can improve clinical processes, which may explain the observed benefit in this study's automation of CLR alerting.

One unintended benefit likely arose from their extensive efforts to link their escalation strategy to physician scheduling. The published recommendations for directing CLRs to physicians favour a ‘role-based’ approach that forwards alerts to a generic physician role (eg, hospitalist on call) instead of an individual (eg, Dr Smith).7 Our own CLR alerting project highlighted this shortcoming in our institution's local paging practices, which led to the subsequent redesign of our overall paging process to incorporate role-based paging protocols that link directly to the physician call schedules. These changes improved the reliability of our paging communication by 80%.10

The work done by the research team to link the automated alerting escalation protocol to the physician call schedule essentially takes a role-based approach, and required each clinical service to make clear the physician call scheduling for their service. We suspect that clarifying the paging hierarchy for each clinical service made all physician communication via pager and telephone more reliable. This likely spilled over to streamline the backup manual telephone alerting process and made it easier to track down an on-duty physician who is ready and available to receive and intervene on a CLR. In fact, establishing clear lines of communication for paging or messaging physicians in hospitals is a safety critical step that affects a variety of different contexts. Whether it is to notify a physician about a CLR, a patient who is clinically deteriorating, or a routine task that needs to be addressed, the common denominator is having a system in place that will deliver the message reliably to a physician each and every time.

Another potential unintended benefit might relate to the ubiquitous use of smartphones by physicians to receive the CLRs via the automated pathway. Although the expected benefit is that physicians can acknowledge a CLR by simply replying to a text message with their phone, there is also the added capability of phoning on the spot to the medical ward to address the issue, or forwarding the CLR alert to another physician who is more directly involved in the patient's care to intervene. Recent descriptions of smartphone use on inpatient general medicine confirm that physicians use the smartphone to direct care remotely, often taking advantage of the text messaging functionality to coordinate care with other physicians.11 All of this might happen without an actual acknowledgement text message, so that a CLR might be intervened upon without a formal response or acknowledgement from the lab's perspective.

Like all health IT implementation, the use of automation to report CLRs to physicians should not be undertaken without careful consideration of the existing clinical processes. This attention to detail serves a variety of important purposes: (1) It allows the automation to have the highest likelihood of achieving its intended outcome by integrating it with existing clinical processes and workflows; (2) The automation's unintended negative consequences are anticipated and potentially mitigated; and (3) The indirect benefits of the automation can be taken advantage of and used to extend the benefits of the intervention more broadly. Keeping these steps in mind and having a detailed understanding of the process are ‘critical’ for success.