Abstract
Disaster plans, during the actual disaster, often do not function as conceived and designed. Disaster or emergency situations may not present as anticipated in planning sessions confounding the intent of disaster planners. Systems that are created and shelved awaiting the disaster may be dysfunctional when needed due to problems such as failed batteries, forgotten training, misplaced equipment, the retraining curve, or software that has not been updated. We report here the smooth and seamless transition to disaster mode from a system in daily use and therefore operational when needed.
In preparing for battle, I have always found that plans are useless, but planning is indispensible.
Introduction
Despite the existence of high-level national organizations developing guidelines and preparations for disasters, 1 the actual disaster response may still be chaotic. Disaster response can be chaotic due to conflicting guidelines, limited supplies, or the need to assimilate a huge body of information rapidly. 2 Preparation for major urban disasters requires substantial coordination, collaboration, and cooperation. 3 Despite apparent preparedness, “we do not learn from our mistakes” and we “reinvent the (disaster) wheel with every new event.” 4 Mid-course corrections or on-site improvisations may be the rule. 5 Recurrent failures include logistics and communications. 6 The bottom line: plans do not necessarily work as planned, mistakes are made, 7 or services not delivered.
While not explicitly stated, systems intended for disaster response may be more likely to fail if they are not in routine usage and kept on a shelf. When needed, these open-only-in-case-of-emergency systems may be found to be unfamiliar or elements of these system may be discovered to be nonfunctional. We describe here a system that is in continuous use during nondisaster times, kept operational from day-to-day, and therefore was fully operational during a disaster event. There were no issues of learning the process, re-familiarizing with a particular technology, or struggling with technical disaster manuals. Additionally, this particular disaster was not on our list of potential events and therefore provided an opportunity to prepare for another unexpected event.
Background
In 2004, the disaster preparedness committee of a small urban community hospital in Baltimore, Maryland, designed a telemedicine component to the facility disaster response program. The telemedicine program was supported by a federal grant from the Health Resources and Services Administration (HRSA) based upon the following four precepts: 1. If medical personnel were unable to travel to the facility due to disrupted infrastructure (impassable bridges, roads, etc), then patient care could be directed remotely via telemedicine. 2. If medical personnel were restricted from traveling to the facility due to radioactive clouds, security-related road closure, etc., again, medical care could be directed remotely. 3. If a surge of patients arrived at a hospital entrance with unknown injury or exposure, initial triage could be performed remotely via a telemedicine device, thereby avoiding exposure of hospital personnel. 4. In the event of rare or unfamiliar manifestations of disease, injury, or exposure, an expert could be virtually brought to the bedside for consultation such as an infectious disease expert from the Center for Disease Control and Prevention.
Baltimore is located in a temperate climate zone and is subject to occasional severe summer or fall storms and hurricanes. Significant or crippling snowfall is a rarity. Baltimore is also in proximity to the Nation's capital—an area that is a focus or ground zero for terrorist organization plots. As a result, our disaster planning primarily focused on preparation for severe summer storms, human-made disasters, and/or acts of terrorism. Fundamental to the program was that after Hurricane activity or human-made disasters, the Internet would likely be functional.
Process
The HRSA grant supported the purchase of an InTouch Health robot (Santa Barbara, CA) in 2004. Immediately, upon installation of the equipment, basic disaster plans were developed and then shelved waiting for the eventual disaster. In the interim, the robot was incorporated into daily work routine in an Intensive Care Unit (ICU). Intensivists are onsite in the ICU daytime and home at night. Evening coverage is supplemented by virtual robotic rounds conducted remotely from homes, by the intensivists at 10:00 pm.
A de-centralized network was established (Fig. 1) connecting physician's homes using the Internet for connectivity. Internet bandwidth requirements are approximately 350–500 kilobits per second (kbps) both up and download. All physicians had robot control stations placed at their homes. Commercially available Virtual Private Network software was installed in the control stations to facilitate connection to the hospital Web-enabled digitized radiographic system (Picture Archiving and Communications System or [PACS]) and Clinical Information System (CIS).

Decentralized Tele-ICU network centered around a single medical facility ICU. ICU, Intensive Care Unit.
The remote presence technology or robot is a semi-autonomous, remotely controlled, real-time, two-way audio–video platform that delivers the clinician to the bedside (see left image, Fig. 2). The remote clinician is able to drive the device in a wireless environment (see right image, Fig. 2), throughout the ICU from the home control station without on-site assistance. In addition to the audio–video capability, peripheral equipment may be added such as electronic stethoscope, opthalmoscope, or ultrasound imaging.

Left image above showing a robot that has arrived at the bedside of an ICU patient. The clinician is then able to visually examine the patient, review all graphics and function of life support devices, and converse directly with the bedside nurse. Right image: MD Home Tele-ICU indicating the Clinical Information System on left-hand monitor, the view through the robot in the middle monitor, and the radiographic images on the right screen. On an independent screen to the far right is a clinical knowledge base (Up-to-Date, Wortham, MA).
During 2004–2009, intensivists made more than 3,000 robotic virtual visits to the ICU. This routine daily experience allowed the intensivists and on-site ICU staff to develop a practicing expertise with the technology. During this routine usage of the system, whenever technical or process issues were identified, the problem would be resolved in a timely fashion, thus ensuring a much greater likelihood of function of the system during a disaster. During the winter of 2009–2010, disaster struck as three major winter storms paralyzed Baltimore, leaving the Intensivists unable to drive to the hospital. The following is a report of a seamless transition to disaster mode.
Event
On Saturday, December 19, 2009, the first of three blizzards hit the Baltimore metropolitan area (Fig. 3), leaving approximately 33′′ of snowfall. The second blizzard occurred on Friday, February 5, 2010, depositing 25′′ of snow. As the region was working to clear this second snowfall, a third blizzard hit on February 10, 2010, adding another 33′′ accumulation of new snow.

Three major snowstorms of the 2009–2010 winter.
In anticipation of snowfalls, surgical hospitalists and nursing staff remained in the hospital overnight. On the mornings of December 19, 2009, and again on February 10, 2010, travel was impossible as snow clearance crews were overwhelmed by the sheer volume of fallen and drifting snow. The intensivist notified key hospital personnel of plans to activate disaster care mode.
The intensivist remained home, accessed all patients via robot, and reviewed all radiographs and clinical laboratory data via the Web-enabled PACS and CIS. From the robotic telemedicine platform at the patient bedside, all graphical data were reviewed to include vital signs, physiologic wave forms, ventilator wave forms, as well as function of life support equipment. Each bedside nurse was interviewed for information regarding patient care-related issues. Ventilator adjustments were made, infusions of vasoactive medications, volume expanders, and medications were adjusted as needed. The process of care, as described above, was identical to prior routine care provided remotely. On-site staff, including nursing and surgical house officers, had become very familiarized and comfortable with the technology over the prior 5 years. There was absolutely no additional training required to provide this disaster care. There were no manuals to seek out and review, there were no new devices to re-learn, nor were there any devices found to have discharged batteries, etc.
A physician care plan in the form of a daily progress note (Fig. 4) was developed, sent to the ICU electronically, and incorporated into the medical record. Each progress note had the following comment clearly stated “Exam and Eval done Remotely due to Blizzard conditions. Pt [sic: Patient] seen, all graphics, labs and X-Rays seen.”

De-identified front and back of patient care plan and progress note developed during blizzard conditions from home of intensivist.
Virtual follow-up was performed twice more during the 24 h before roads were cleared enough to be passable. During routine virtual follow-up visits, further adjustments to life support equipment, infusions, and vasoactive agents were made as necessary. There were no untoward events. Nursing, administrative, and patient acceptance was high. The technology worked seamlessly during disaster mode.
Subsequently, professional billing was submitted for physician services with follow-up through the finance department.
Discussion
Prepared-but-unused disaster plans may not work when needed due to failed equipment, forgotten instructions, un-familiarity, or staff changes since the initial training. During this event, function was flawless largely due to the continued utilization of the technology with continuous maintenance of equipment and personal skills. There was no issue of initiation or activation of the system since the disaster application was a mere re-naming of the daily routine. Staff acceptance was equally seamless as was patient acceptance.
While not an element of the initial disaster plan, it became evident that snow blizzard conditions limiting travel were as disabling as summer storms and perhaps terroristic events. Events in the United Kingdom on December 8, 2010, mimicked the events in the United States with snow paralyzing roads and airports yet telehealthcare was sustained and functional. 8 More recently, a major snow storm paralyzed New York City 9 with several reported cases of loss of life related to restricted capability of the Emergency Medical System. 10,11
In this event, telecommunications was preserved via the traditional hard-wired telephone lines. Now with the availability of wireless broadband technology and with quality compression technology, even the loss of some elements of the hard-wired telephone system, the telemedicine program could continue to provide virtual presence.
The resource most often limited during a surge or disaster event is human resources, to include nurses 12 and physicians. While, conceptually, nursing could be supplemented by paramedics and perhaps the Public Health Service Commissioned Corps, 13 there are fewer options for the supplementation of physicians. The telemedicine Tele-ICU provided knowledgeable and trained bedside personnel rather than using alternative, less trained staffing.
To emphasize the point, during the storm of February 5, 2010, a different covering Intensivist, who lives in the city of Baltimore walked the two miles to the hospital, completed on-site patient care duties, and then walked back to his home. Again, during this storm, travel by motor vehicle was unfeasible.
Regarding payment for professional services, this particular medical facility is located in a medically underserved area, but not a rural site. Therefore, there was no Medicare billing codes to cover these services. Nonetheless, all services were paid with the exception of a single self-pay. In all cases the telemedicine common procedure terminology (CPT) billing modifier, “GT,” was addended to the billing code and a copy of services provide were submitted with the clear statement that care was provided remotely. Curiously, even bedside critical care time billed as 99291-GT was paid in full as if the physician was actually at the bedside rather than virtually present.
To the point of building disaster preparedness programs on existing functional programs, there are currently at least 10% of the ICU beds in the United States under the management of Tele-ICU technology. These programs operate 12–24 h per day and, as a consequence, maintain functionality. Many of the Tele-ICU programs have a closed architecture that prohibits or limits access to patients or patient information from physician homes. However, independent of whether the program is open or closed architecture, travel to a single Tele-ICU site could be more feasible than travel to multiple medical facilities. Therefore, it is reasonable to incorporate any existing Tele-ICUs into a hospital disaster response program.
Conclusions
Disaster planning is often an iffy proposition with even the best plans subject to change as unforeseen circumstances will dictate. Compounding this conundrum are plans that are created and placed on a shelf awaiting the disaster. Lack of familiarity by staff and/or technical challenges can doom these shelved plans to failure. Our experience showed that a program that works routinely and daily could seamlessly transition into disaster mode. The process of care was unchanged just the name was changed for a few hours. In this particular case, we extended the Tele-ICU technology to disaster support. Currently, it is estimated that about 10% of the±96,000 ICU beds in the United States are supported with telemedicine technology, which generally operates 24×7. Therefore, there is a major opportunity to develop a substantial disaster preparedness model based upon these active, existing programs.
Footnotes
Disclosure Statement
No competing financial interests exist.
