Increasing Operating Room Throughput

We read with interest the article by Smith et al. , and we congratulate the authors on increasing both major joint arthroplasty throughput and profitability by implementing a parallel processing system.1In their model, the authors describe the anesthesia induction room as either an “underutilized operating room (OR)” or “a shared induction area bed space.” If at all possible, however, we feel it is superior to have a dedicated block room (BR), although we accept that this might not always be feasible. We wish to briefly explain our current model at the Toronto Western Hospital, Toronto, Ontario, Canada, which includes a spare OR and a BR. We believe that our model capitalizes on the most important advantages of both a parallel processing system and a BR, which, as alluded to by Smith et al. , has already been shown to reduce anesthesia-related OR time. We are fortunate to have a four-bedded BR, wherein over 3,600 blocks are performed annually, staffed by a regional anesthesiologist, regional anesthesia fellow, anesthesia resident, two anesthesia assistants and one nurse. A BR allows for concentration of expertise and resources, both human and technical. The BR team has immediate access to all necessary equipment, such as bedside monitors, sterilization trays, needles, catheters, nerve stimulators, ultrasound machines, local anesthetics, opioids, and exclusive resuscitation materials, including intralipid, that is required for any nerve block, thus sparing the duplication or multiplication of this costly equipment for each additional “induction room” inherent to a true parallel processing system. Moreover, a BR can be an ideal training facility for both fellows and residents, who learn from the both the dedicated BR consultant regional anesthesiologist and one another without the intimidating OR environment. Finally, with appropriate time management, the BR allows us to block many patients who would otherwise be excluded in the parallel processing system described by Smith et al. , such as those with severe comorbidity, high body mass index, or patients with previous spinal surgery. For example, invasive monitoring when required is often instituted in the BR, further enhancing throughput by reducing anesthesia-related OR time. After successful block placement, patients are transferred to the spare OR by a member of our anesthesia care team who then assumes care of the patient for the remainder of the case. Two supplementary nurses charged with opening and counting instrument sets in the spare OR have already prepared this spare OR in anticipation of the patient’s arrival.Analysis between 2006 and 2007 has indicated that our combined parallel processing and BR model has increased throughput by 0.3 arthroplasties per day, at the expense of 0.7 full time nursing equivalents per day. Turnover time was reduced by 44% to 18.5 min. Although the new model allowed for five major arthroplasties per day rather than four, the average increase of only 0.3 per day was primarily due to insufficient cases being scheduled. On every day for which five cases were listed, this target was met without cancellation. Interestingly, although we believe a BR is advantageous, it has actually been identified as an area which could occasionally be a source of delay. The BR serves many ORs; if patients do not arrive there as planned (often for reasons beyond the BR’s control), a bottleneck can occur. There is therefore still scope for improvement in our model, as evidenced by the fact that turnover time in some instances was as low as 7 min.Every hospital requires that personnel, plant modifications, and equipment are tailored to its own requirements to develop an effective perioperative patient flow system. We would advocate the use of a BR, however, as part of this process for the reasons outlined above.*Toronto Western Hospital, University of Toronto, Toronto, Ontario, Canada. richard.brull@uhn.on.ca

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.