In an environment where we’re constantly looking to automate processes, we at Boston Children’s Hospital found ourselves treading backwards during a downtime, utilizing a lot of humans to replicate processes that our computers normally handle. In sharing our story, we hope that others learn from our experiences, outlined below, to develop better processes in their laboratories.
Our clinical systems, including the lab information system (LIS), experienced a 5-day downtime. During this period, our analyzers were functional but unable to receive orders or send results to the LIS. Our dependence on technology quickly became evident. Our downtime policy clearly was not sustainable for a prolonged event, so we took the opportunity after the crunch was over to re-evaluate our process.
We decided to rebuild our entire process from scratch due to the many bottlenecks in our system. Our goals remained the same, but we wanted a seamless process that minimized, if not eliminated, all hurdles. We had three aims: to improve the downtime process without compromising patient results; to minimize potential errors; and to not delay turnaround time.
Plotting the Process
We started by enlisting help from our strongest asset, the medical technologists who were in the downtime trenches. They uncovered many limitations in our procedures and policies. We conducted chalkboard sessions with them to determine what worked well and what needed to be improved. With their feedback we pinpointed strengths and weaknesses during the major phases of our down-time processes. This enabled us to parse the process into six major phases, including activation, lab control, testing benches, resulting, recovery, and deactivation (See figure below).
One of the biggest challenges we faced in revamping our downtime procedures was in setting parameters for when to activate the downtime plan. On the surface, it would seem obvious when a lab goes into downtime, but we found that early-on staff are trying to make sense of what’s happening and may not be focused on formally triggering the downtime plan. We fixed this by requiring communication with higher administration and with the lab information technology (IT) team as soon as we recognize a problem.
Now, we will conduct only STAT testing in the first 15 minutes and give the IT team a chance to assess the situation. If they’re unable to determine how long the system will be unresponsive we will activate our downtime procedure. This process involves setting up the resulting center, sending out test faxes, communicating with the technologists and crucially, recruiting additional staff, as we will need help to do the same work as our computers.
Supporting Lab Control
Lab control, our specimen processing area, is the next phase. During our days-long downtime, samples were arriving at lab control with incomplete and sometimes illegible paper requisitions that contained only patient information, no barcodes that normally would have been used to scan them on to the instruments.
In our technologically advanced world, lab control staff were manually placing dedicated down-time labels with accession numbers on each tube and handwriting two unique patient identifiers on each aliquot tube. In our redesign, we created a dedicated downtime requisition with disclaimers stating that testing won’t be performed without the minimum required information.
Additionally, after consulting with clinicians we agreed upon a limited test menu to accommodate our patient population. We also bought extra printers to print patient demographic labels from our patient management system. This circumvents having to write labels by hand.
In the testing phase, tests were being ordered manually on the instruments since orders couldn’t be transferred electronically. Frenzied technologists were printing and faxing the results rather than verifying results electronically as normal. The pile of papers continued to grow and our phones were ringing constantly, with multiple people calling about the same results.
Unfortunately, we couldn’t alleviate manual test ordering on the instruments. However, in our re-vised plan we created a systematic resulting process such that technologists will print only one copy of any result to limit the inevitable piles of paper. We also mimicked our normal process by annotating on printed test results any calls made for critical values. And we developed a dedicated area for results organized in boxes by testing benches. Each box will have folders for each patient sorted by last name to facilitate communicating results with providers.
Handling Retroactive Orders
During the recovery phase, our staff had to cope with retroactively ordering tests in the system while also taking care of new test orders. The recovery phase was filled with confusion given that every-one was ordering and verifying tests that had already been completed. In our revised downtime plan, only lab control staff will order tests in the electronic medical record.
The new plan also calls for additional technologists to verify test results by each testing bench. In addition, we’ll have a dedicated extra person resolve any discrepancies between test orders and results.
In our original process, we did not have a deactivation phase. In the new plan we will use this time to clean up and ensure a state of readiness for any future downtimes.
Unfortunately, we had the chance to evaluate and refine our new process in a subsequent unplanned downtime later the same year. However, we were gratified to find that our new process curbed the entropy in our system and that our staff could functionally replace computers. Simplicity, accessibility, and organization ensured efficiency and sustainability. Ultimately, our new process has enabled our laboratory to be prepared all the time for downtimes.
Yachana Kataria, PhD, DABCC, is assistant director of clinical chemistry at Boston Children’s Hos-pital in Boston, Massachusetts. +Email: yachana.kataria[at]childrens.harvard.edu.