Tele-ICU Network Design: Hub, Spokes and Escalation Rules

The physical hub is smaller than most people imagine and more particular about detail. A working console needs two or three displays: one carrying the patient list and alert queue, one carrying the clinical record and orders for the patient currently in focus, and one carrying live video and waveform from the bedside. Add a headset with reliable noise isolation, because a hub with four intensivists talking simultaneously is unusable without it, and a hard-wired network drop rather than wireless.

Acoustics and lighting do more for adoption than the software does. Consultations are clinical conversations with distressed families and tired registrars, and a room that echoes makes every one of them worse. Similarly, camera-facing lighting matters because the spoke team is reading the intensivist's face for confidence. These are unglamorous line items that get cut first in a capital plan and get regretted within a month.

Do not put the hub somewhere symbolic. Put it where intensivists already are, so that a hub shift is a shift they can take between their own unit rounds rather than a separate commute. Hubs built in corporate offices for visibility reasons struggle to roster, and rostering is the constraint that decides whether the network survives its first year.

Published tele-ICU models internationally have used intensivist-to-bed ratios spanning a wide range, and the numbers quoted in vendor material tend to come from mature programmes with heavy automation and highly standardised spokes. Do not import a ratio. Derive yours from the acuity of the beds you are actually covering, the experience of the spoke teams, and the volume of active interventions per night, and then measure it for a quarter before you commit to a second wave of spokes.

The number that decides the design is not the average night. It is the worst plausible night, when two spokes have simultaneous deteriorations and a third has a family conference that cannot be deferred. Staff for that, or write down explicitly what gets dropped when it happens and make sure the spokes know. A network that silently degrades under load teaches spoke teams not to trust it, and once trust goes, calls stop coming in early and only arrive when the patient is already in trouble.

Pair the intensivist with a critical care nurse at the hub. The nurse handles the alert queue triage, the routine data review, the documentation, and the first contact with the spoke, which lets the intensivist spend their attention on decisions. Most programmes that struggle with intensivist fatigue are missing this role, and adding it is cheaper than adding a second consultant.

Every tele-ICU eventually loses its link, and the design question is what happens in the ninety seconds after that. Dual internet paths from different providers at both hub and spoke, ideally one fibre and one wireless, with automatic failover and a documented fallback to plain telephony. The fallback matters more than the failover: the spoke team must know the number to dial and must have used it in a drill, because the middle of a code is not when to discover the escalation phone list is out of date.

Bandwidth planning should be done per bed, not per site, and should account for what you actually stream. Continuous high-definition video from every bed is expensive and rarely necessary; a common pattern is continuous device and monitor data with video invoked on demand for a specific bed. That single choice can change your connectivity budget by an order of magnitude and is worth modelling before you sign a circuit contract.

Power deserves the same treatment. A spoke ICU on a generator during a long outage may keep monitors alive while the network switch and the camera sit on an unprotected circuit. Walk the actual power path for every tele-ICU component during commissioning and put the network equipment on the same protected supply as the ventilators. This is a thirty-minute check that prevents a class of failure that looks like a software problem and is not.

The protocol has to answer three questions without ambiguity: what triggers a call to the hub, how fast the hub must respond, and who decides when the two clinicians disagree. Triggers should be objective and written as a short list the bedside nurse can apply without asking permission, built on the early warning score your group already uses rather than a new scale invented for the network. Response times should be defined by trigger severity and measured, not asserted.

The disagreement question is the one hospitals avoid and the one that decides clinical safety. The workable position in most Indian networks is that the treating practitioner at the spoke retains responsibility for the patient and the hub intensivist advises, with the advice recorded in the patient record either way. That preserves the legal position while making the advice auditable. What must not happen is a culture where the hub gives an instruction, the spoke quietly disagrees, and nothing is documented.

Write the protocol so it is usable at three in the morning by a nurse who joined last month. One page, laminated, at the nurses' station, with the trigger list, the number, and the three pieces of information to have ready when the call connects. Everything longer belongs in the training file, not at the bedside.

A tele-ICU is a practitioner-to-practitioner arrangement under the Telemedicine Practice Guidelines, which is a lighter regime in some respects than direct patient teleconsultation but not an unregulated one. The hub intensivist must be a Registered Medical Practitioner, the advice must be recorded, and the identity of the advising clinician must be traceable on the spoke's record. Privileging is a hospital obligation on top of that: each hub intensivist should be formally privileged to advise at each spoke, with the scope written down.

Get the contractual position clear before the first patient. Which entity employs the hub intensivist, which entity's insurance responds to a claim, how indemnity is arranged across the group, and what the spoke's own consent process tells patients about remote involvement in their care. These questions are tedious and they are much cheaper to answer in a boardroom than in a consumer commission.

Governance should meet monthly with real cases. Review every transfer, every death, and a sample of routine consults, with both hub and spoke clinicians present. Networks that run this meeting develop shared clinical standards across sites, which is the underrated long-term benefit of a tele-ICU. Networks that do not become a set of parallel ICUs sharing a video link.

The full-fat model with a purpose-built command centre, continuous data ingestion, and dedicated round-the-clock intensivist cover is out of reach for most three-to-five hospital groups in India, and pursuing it usually ends in an abandoned pilot. The variant that works is narrower: night-only cover, two consoles rather than eight, video on demand instead of continuous streaming, and a hard scope limited to deterioration events and admission decisions rather than routine rounding.

Sequence it so that value arrives before the capital does. Start with a scheduled tele-round at a fixed time each night across all spokes, which requires nothing more than reliable video and a shared patient list, and which immediately standardises how sick patients are discussed. Add on-demand escalation next. Add device data ingestion last, because it is the most expensive component and the least useful until the human protocols are working.

Be candid in the business case about what you are actually saving. The gains are usually in avoided inter-hospital transfers, earlier recognition of deterioration, and retention of cases at spokes that would otherwise refer out, not in reduced staffing. Model those, agree with finance how they will be counted, and instrument them from day one. A tele-ICU justified on a benefit nobody is measuring will be cut in the first cost review.