NURS 718 Week 4 Case Study 2 on Telecommunications Infrastructure for Telehealth Example

Case Study 2: Four Minutes of Frozen Video, Infrastructure, Security and Downtime Planning for Telehealth in a Critical Access Hospital

Case Summary

During the second month of a telestroke pilot, a 71-year-old woman was brought to the small hospital's emergency room with weakness on her right side and difficulty speaking that had begun forty minutes earlier. The nurse rolled the telestroke cart to the bedside and connected to the neurologist at the comprehensive stroke center. Midway through the neurological examination, the video froze and the audio dropped. For four minutes, the nurse tried to reconnect while the neurologist waited on a phone line that no one had thought to open. The connection returned, the examination was completed and thrombolysis was given, but the door-to-needle time exceeded the target by eleven minutes. The hospital has one commercial internet connection, two information technology staff who work days, and a telestroke cart that had not received a software update since installation.

Question 1: What Infrastructure Does Telehealth Require?

Tan and Payton (2010) describe information systems as resting on technical infrastructure, including networks, hardware, software and the people who support them, and clinical applications are only as reliable as that foundation. Telehealth for acute stroke has unusually strict requirements: high-quality, two-way video and audio with very little delay, available at any hour, from a cart that can move to the bedside or the imaging suite. That requires adequate bandwidth reserved for the clinical video, a redundant connection from a second provider, wireless coverage throughout the emergency department and imaging areas, managed devices that receive updates and are monitored for problems, and technical support available around the clock, either in house or through the vendor or the hub hospital.

Question 2: What Caused the Failure?

The root cause analysis points to four contributing factors. First, the hospital relied on a single internet connection with no failover. Second, the cart's software had not been updated, and the vendor later reported a known issue with reconnection in that version. Third, wireless coverage was weak near the room where the patient was being examined. Fourth, there was no downtime procedure, so the nurse focused on reconnecting rather than switching immediately to a telephone consultation that could have continued the history and decision-making. The video failed for technical reasons, but the delay grew for a human one: no one had decided in advance what to do when it failed.

Contributing Organizational Factors

Behind the technical causes lay organizational ones. The pilot was launched on the vendor's standard checklist, which assumed an urban hospital with a dedicated information technology team on site around the clock. No one had tested the cart in every room where a stroke patient might be examined, and no one had been assigned to own the cart between consultations. The hub hospital assumed the spoke would manage its own equipment, while the spoke assumed the hub's telestroke program would. Each gap was small, but together they meant that nobody was responsible for readiness.

Question 3: What Security and Privacy Safeguards Are Needed?

Telehealth carries protected health information across networks, so the system must use encrypted connections, authenticated access and devices managed by the organization rather than personal phones or laptops. The cart should be locked to its clinical function, sessions should not be recorded unless policy requires it and the patient is informed, and access logs should be reviewed. Because the critical access hospital's information technology staff is small, the hospital should rely on the hub hospital's or vendor's security monitoring under a written agreement that defines responsibilities. Security measures must not slow access in an emergency, which argues for single sign-on and a cart that is ready the moment it is powered on. The hospital should also complete a security risk assessment of the telestroke workflow, including the video platform, the cart, the network path and any images shared with the hub, and repeat it whenever the system changes.

Question 4: What Should Downtime and Contingency Planning Include?

A downtime plan should specify that every telestroke consultation begins with an open telephone line to the neurologist alongside the video, so that a video failure becomes a switch rather than a gap. It should include a printed stroke checklist and the hub's direct number at every cart, a two-minute rule after which the team proceeds by telephone, and a process for reporting every failure to the information technology team and the telestroke program. The World Stroke Organization's statement on telestroke in resource-limited settings emphasizes quality assurance and pragmatic models adapted to local resources (Tunkl et al., 2026), and a simple, rehearsed fallback is exactly such an adaptation.

Question 5: How Does Staff Readiness Affect Performance?

Technology reliability depends partly on the people using it. In a survey of 135 health professionals in an island stroke network, respondents scored telemedicine's value above its fit with how their units actually worked, and barely six in ten had watched a system operate (Chatzidaki et al., 2026). A mixed methods review of digital health in rural areas likewise identified workforce constraints, including staff shortages and heavy workloads, alongside technical problems and poor connectivity as key barriers (Sahakyan et al., 2026). For this hospital, readiness means monthly simulated consultations that include a planned video failure, so nurses practice switching to the telephone, and a named nurse champion on each shift who knows how to restart the cart.

Christian Reflection

Jesus told a parable of ten virgins, five of whom brought extra oil for their lamps and were ready when the bridegroom came at midnight (English Standard Version Bible, 2001/2016, Matthew 25:1-13). Preparation for failure is part of faithful care. A patient whose stroke treatment depends on a video link deserves an organization that has prepared for the moment the link fails.

Conclusion

The four-minute failure resulted from a single connection, outdated software, weak wireless coverage and the absence of a downtime plan. Most of the fixes are low in cost: a managed update schedule, an access point, a written procedure with a telephone backup and regular simulation. The one moderate investment, a redundant connection, should be a condition of expanding the telestroke network. These steps will be built into the infrastructure section of the HMIS project.

References

Chatzidaki, S., Anargyros, K., & Xanthos, T. (2026). Human readiness for stroke telemedicine in a Greek island network: A cross-sectional study. Telemedicine and e-Health. Advance online publication. https://doi.org/10.1177/15305627261492660

English Standard Version Bible. (2016). Crossway. (Original work published 2001)

Sahakyan, S., Akseer, S., Abrahamyan, L., Metcalf, O., Allin, S., Chenhall, R., & Seto, E. (2026). Barriers and facilitators to implementing digital health technologies for remote management of NCDs in rural areas: Mixed methods systematic review. Journal of Medical Internet Research, 28, Article e93875. https://doi.org/10.2196/93875

Tan, J. K. H., & Payton, F. C. (2010). Adaptive health management information systems: Concepts, cases, and practical applications (3rd ed.). Jones and Bartlett.

Tunkl, C., Carbonera, L. A., Hubert, G., Agarwal, A., Adcock, A. K., Liberato, B., Yperzeele, L., Roushdy, T., Collantes, E. M., Bonifacio Delgadillo, D. M., Bladin, C., & Ranta, A. (2026). Telestroke care in resource-limited settings: A World Stroke Organization scientific statement. International Journal of Stroke. Advance online publication. https://doi.org/10.1177/17474930261480603