A hospital is not one network. It is several networks that happen to share a building, a cable tray and a comms cupboard. Clinical systems carry patient information and cannot tolerate interference. Biomedical devices sit on the network for years with firmware nobody wants to touch. Staff move between wards, theatres and diagnostics while holding a live session. Patients and their attendants expect guest Wi-Fi that never comes anywhere near any of it. Immunity Networks designs, manufactures and supports the equipment that keeps those worlds apart while running them on one manageable estate.
Healthcare brings together three conditions that individually make wireless difficult, and together make it a design discipline of its own.
The first condition is that there is no maintenance window. A hospital does not close on a Sunday night, and it does not schedule a two-hour outage for a firmware upgrade. Every change has to be made alongside live clinical operations, which rules out the approach most other sectors take for granted. Hospital networking therefore has to be built so that work can proceed area by area, with each area validated before the next one is touched, and with the existing network still carrying traffic while the new one is commissioned beside it.
The second condition is that the building actively fights the signal. Dense masonry, lead-lined imaging rooms, metal-framed beds, equipment trolleys parked against walls, fire doors that close on a corridor, and long service spines with plant rooms at intervals all attenuate and reflect radio energy in ways a floor plan does not disclose. Clinical network infrastructure that models cleanly on a drawing very often fails in the ward, and it fails in exactly the places clinicians need it — at the bedside, in the treatment bay, at the threshold of a shielded room.
The third condition is that traffic separation is not a preference but a requirement you have to be able to evidence. It is rarely enough to tell an auditor or an accreditation assessor that guest Wi-Fi is separated from clinical systems. You have to be able to show how, in a way that survives staff turnover and configuration drift. That single requirement is the deciding architectural factor on almost every hospital project we quote, and it is where our healthcare wireless solutions start rather than where they finish.
The deciding architectural factor. Everything else in the design follows from it.
We design hospital networks on one principle: clinical, biomedical, staff, building-services and guest traffic share the physical infrastructure and nothing else. Each class sits on its own VLAN, enforced in switching hardware by NetForce L2 and L3 switches, with inter-VLAN policy applied at the NetGuard controller. Isolation implemented that way is structural. It is written into the port configuration and the routing policy, not into a firewall rule that a hurried change one evening can quietly undo.
In practice we usually end up with five or six classes on a hospital estate. Clinical systems — the hospital information system, the electronic medical record, laboratory and pharmacy applications, PACS traffic from imaging — form the first. Biomedical devices form the second, and deserve their own class rather than being folded into clinical, because they behave completely differently: long lifecycles, vendor-locked firmware, and often no realistic patching path. Staff devices form the third. Building and security systems — CCTV, access control, nurse-call, lift and BMS panels — form the fourth, and are frequently the least maintained equipment in the whole building. Patient and visitor guest access forms the fifth, and gets internet egress and nothing else. Some groups add a sixth for research or teaching traffic where the hospital is attached to a medical college.
Client isolation matters as much as VLAN separation on the guest network. Patients and attendants sit in shared bays with phones, tablets and laptops on the same SSID, and there is no reason for any of those devices to be able to see each other. We turn client isolation on by default in the guest profile and treat it as part of the segmentation design rather than an option. The gateway security policy then handles what leaves the guest segment, with time-bound sessions, per-user bandwidth ceilings and portal-based onboarding so that the hospital has an identity attached to each session.
We survey and design per zone, because a ward, a theatre and an outpatient waiting hall are entirely different radio problems.
Hospital coverage design begins with a walk of the live building, including the areas that fail today. Where an existing network drops is the single most useful piece of evidence available to us, because it tells us what the drawings do not — which walls are denser than they look, which trolley bays sit in a null, which corridor junction produces a handover that never completes. From there we build a zone map and size each zone on its own terms.
Wards and bed bays need consistent signal at the bedside, through partitions and curtain rails, rather than a corridor-only deployment that gives good numbers in the walkway and poor ones where the work happens. Theatres and procedure rooms need predictable behaviour close to shielded structures. Diagnostics and imaging suites are the hardest case: shielding produces sharp, predictable dead zones, and the design problem is not covering inside the shielded room but making sure the threshold and the adjacent corridor do not become a roaming trap. Outpatient and waiting halls behave like a public venue, with high visitor device counts and a heavy guest onboarding load. Corridors, lift lobbies and stairwells are pure roaming problems, tuned for clean handover rather than maximum transmit power. Grounds, ambulance bays and link corridors between blocks need ruggedised outdoor units.
Indoor coverage across wards, theatres, corridors and outpatient areas is delivered by NetWave Lotus Alpha indoor access points, with the outdoor variants of the NetWave Wi-Fi range handling grounds, ambulance bays and open circulation. Where blocks are separated by distance, inter-building links run over fibre using NetBeam optical transceivers into the L3 core rather than over improvised wireless bridges. Ask us to confirm current specifications in writing for the exact models proposed in your design.
Sized for bedside signal through partitions, curtain rails and metal-framed beds rather than for corridor readings. Trolley-mounted workstations and handhelds are the design reference, since these are the devices clinicians actually carry.
Predictable behaviour near shielding and heavy equipment. Coverage is planned around the structure rather than discovered after installation, and validated in the space before the phase is signed off.
Visitor device density closer to a transport terminal than to an office. Guest onboarding load, portal capacity and per-user ceilings are designed alongside the radio plan, not bolted on afterwards.
Connected medical equipment is the part of a hospital estate that most often gets attached without a plan, and is hardest to change afterwards.
Infusion pumps, patient monitors, ventilators, point-of-care analysers, ECG carts, ultrasound units and a long tail of diagnostic equipment increasingly arrive with a network port or a radio and an expectation that they will be connected. These devices are not ordinary endpoints. Their firmware is controlled by the equipment vendor and is frequently tied to a regulatory approval, which means the hospital cannot patch them freely. Their lifecycle is measured in years rather than refresh cycles. Many of them speak older protocols, some of them are noisy, and a few behave badly when they lose a link.
The practical answer is not to secure each device individually — the hospital usually cannot — but to place them where their weaknesses matter least. A dedicated biomedical segment with tightly drawn policy at the NetGuard controller limits what a device can reach and what can reach it. Where a device class needs to talk only to one vendor server or one gateway, the policy says exactly that. Where a device needs no internet access at all, it does not get any. Port-level control on NetForce switching means an unplanned device plugged into a ward socket does not silently join a clinical segment.
Biomedical and IT teams also need to agree on who owns what before the first device is onboarded. In our experience the projects that go well are the ones where biomedical engineering, IT and the equipment vendor sit in the same design conversation early, and the ones that go badly are the ones where a device arrives on a Friday with an installation engineer and a request for an IP address. The onboarding flow below is the process we recommend hospitals adopt, and it is worth writing into the equipment procurement process rather than leaving to the day of delivery. Our hospital network design guide works through the same sequence in more detail.
Clinical work is mobile. The network either follows the clinician or it becomes something to work around.
Ward rounds, medication administration, specimen collection and handover all now happen against a screen. A doctor opens a patient record at the nurse station, walks to the bed with a tablet, moves to the next bay, then heads to diagnostics — and expects the session to survive all of it. When it does not, the visible consequence is a re-login; the invisible consequence is that staff stop trusting the mobile workflow and revert to paper, which is a far more expensive outcome than the network fault that caused it.
Roaming design is therefore treated as a first-class objective in our healthcare wireless solutions rather than a by-product of coverage. Cells overlap deliberately along circulation routes, transmit power is tuned down rather than up so that clients make handover decisions cleanly, and channel planning is done across the whole floor plate rather than per access point. Because the access points, switching and controller come from one Indian OEM on one firmware cycle, policy and roaming behaviour stay consistent across the estate — which is much harder to achieve when three vendors each have their own view of how a client should be handed over.
Handover between shifts adds a second pattern. At shift change, a large number of staff devices associate, disassociate and re-associate in a short window in a small number of places. We design nurse stations, handover rooms and staff areas for that burst specifically. Where a hospital uses voice over Wi-Fi handsets or nurse-call integration, those get their own quality-of-service treatment through the NetForce switching core so that a busy outpatient department does not degrade a clinical voice call.
What a hospital actually needs is not a number on a slide but a way of working that keeps interruptions rare, short and visible.
Critical care areas set the tone for the whole estate. Intensive care, high-dependency units, theatres and emergency departments are where an interruption stops being an inconvenience, and where the operating model matters as much as the equipment. We do not publish availability claims for hospital deployments, because a meaningful figure depends on the design agreed for a specific site, the power and cabling it inherits, and the support arrangement around it. What we do commit to is the discipline that produces good outcomes.
That discipline starts with visibility. NetCloud Central monitors every access point, switch and controller on the estate and raises an alert on a degrading device or a saturated area, so that a problem in a distant block surfaces on a console rather than through a phone call from a ward sister. For a hospital network management team of two or three people covering several buildings, that difference is the difference between a maintenance task and an incident.
It continues with remote operations. Configuration changes, firmware rollouts and first-line troubleshooting are performed centrally rather than by walking to a comms cupboard on the fourth floor of another block. It continues with standardisation: a new ward or a refurbished floor is provisioned from a template, so a building project does not turn into a bespoke networking exercise with its own configuration quirks. And it continues with a single point of escalation — access points, switching, gateway and cloud all come from Immunity, with India-based engineers, so a fault does not become a negotiation between three suppliers about whose problem it is.
Physical and power design is agreed alongside the network design. Comms room locations, UPS provisioning, PoE budgets and cable routes are all part of the same conversation, because a wireless estate is only as available as the switches powering it. Where a hospital wants resilience characteristics designed into the topology, our engineers will discuss the specific options available for your site and confirm what is supported in writing — we do not make blanket claims about behaviour under failure on a web page.
Guest Wi-Fi is a service the hospital offers, and a boundary the hospital has to defend.
Patients on long admissions, attendants staying overnight and visitors in waiting halls all expect connectivity, and hospitals increasingly treat it as part of the patient experience. Delivered properly it costs the clinical estate nothing, because it sits on its own VLAN with its own egress and no route inward. Delivered casually — a spare port, a consumer router, an unsegmented SSID — it becomes the most common way an otherwise sound clinical network acquires an exposure.
Our guest design runs through a branded captive portal on the NetGuard controller, with session duration limits, per-user bandwidth ceilings so that one heavy user does not starve a waiting hall, and client isolation between guest devices. Onboarding can be tied to an identity — a mobile number with one-time password, a voucher issued at reception, or a patient or attendant reference from the hospital's own systems — so the hospital has a record of who was on the network without having to inspect what they did. The same portal approach is used in our hotel Wi-Fi solutions and airport Wi-Fi solutions, where public onboarding at scale is the everyday case.
Branding matters more than it sounds. A portal that carries the hospital's identity, states the terms of use plainly and works on the first attempt reduces help-desk traffic considerably, and in a hospital the help desk is often the ward clerk. We keep the journey to one screen wherever the hospital's own policy allows.
Healthcare buying committees ask questions other sectors do not, and it is better to address them directly than to be asked in a tender clarification.
Indian health data norms are tightening, and hospital IT teams are increasingly asked to describe where patient-related data sits, who can reach it and how access is recorded. A network cannot answer all of that on its own, but it carries a meaningful share of the answer. Because separation is enforced on distinct VLANs in switching hardware with policy applied at the gateway, the design is documentable: you can produce a segmentation diagram, a policy statement and a port map, and show that the guest network has no route to a clinical segment because no such route exists. Access logging and configurable retention in NetCloud Central gives the hospital a record it can produce on request. What retention period and what log detail are appropriate is a decision for the hospital's own data governance, and we will configure to it — ask us to confirm current capabilities in writing for the release you are deploying.
On certification, Indian institutional buyers increasingly require MTCTE, TEC and WPC status for network equipment, and public-sector and trust-run hospitals frequently make it a tender condition. Our advice is the same one we would give about any vendor including ourselves: ask for written, per-model confirmation of certification status rather than relying on a general statement on a website, and check that the confirmation covers the exact SKUs in the bill of materials. We are happy to provide that in writing for the models proposed in your design, and our certifications page explains the documentation we can supply.
Domestic manufacturing is also relevant to many healthcare buyers. Immunity Networks was founded in 2009 and designs and manufactures at our facility in Sanand GIDC, Gujarat, with our head office in Powai, Mumbai. For institutions operating under domestic procurement preferences, that matters commercially as well as technically, and it shortens the supply chain for spares and replacements.
Hospital networks are also commonly funded and built in phases, block by block, across several budget years. We design the target architecture up front so that each funded phase is a step towards it rather than an isolated purchase that has to be unpicked later. A phase-two building joins the existing estate under the same management console rather than becoming a second network with its own conventions. Where a hospital group prefers to buy through a channel partner or a systems integrator, our partner network covers most of the country.
Chosen for predictability and for how it behaves in a building that cannot be taken offline.
Lotus Alpha indoor units across wards, theatres, corridors and outpatient areas, with outdoor units from the NetWave range for grounds, ambulance bays and inter-block circulation.
Managed PoE access switching per floor or block feeding an L3 core, enforcing the clinical, biomedical, staff, building and guest separation in hardware rather than in software policy alone.
Captive portal, authentication and policy in one appliance, applying inter-VLAN rules and gateway security. Works alongside the wider network security design for the estate.
SFP and SFP+ transceivers for fibre uplinks between blocks and back to the core, so inter-building links are engineered rather than improvised.
AIOps cloud management for the whole estate — zero-touch provisioning for new wards, live client and RF visibility, alerting and remote operations from one console.
Hospital groups running several units manage them together under the same console, using the same approach as our wider enterprise networking and campus wireless deployments.
Exact model selection depends on the survey, the density profile of each zone and the existing cabling. We do not publish throughput or coverage figures against a building type, because they would be misleading — ask us to confirm current specifications in writing for the models in your design, and we will send the datasheets alongside the design document.
Five steps, arranged so that clinical operations never wait for the network project.
Survey the live building. Including the areas that fail today, the shielded rooms, the plant spaces and the routes staff actually walk. We record construction type where it is visible and ask about it where it is not.
Design segmentation before hardware. Clinical, biomedical, staff, building systems and guest classes are agreed with IT, biomedical engineering and whoever owns data governance, before a single model number is proposed. The segmentation design is what the rest of the bill of materials answers to.
Phase around clinical operations. Installation is planned ward by ward and block by block, running alongside the existing network, with no dependency on a downtime window. Where a ward is being refurbished anyway, we align to that programme.
Validate after each phase. Coverage, roaming and policy are confirmed in the area just completed before the next one starts. A short validation report per phase is much easier to act on than one large report at the end.
Operate centrally. Ongoing hospital network management through NetCloud Central, with alerting, remote change and capacity reporting, and OEM support from India-based engineers when something needs escalating.
To produce a useful design we need floor plans or a site layout, an idea of concurrent devices at the busiest hour rather than headcount, the traffic classes that must stay separate and any audit requirement attached to them, details of existing switching and cabling, and — most useful of all — a list of where coverage fails today. From that we produce a design document with access point placement, switching and PoE requirements, the segmentation design and the management model. You are free to tender against it, whether or not we supply. You can see how the same approach applies across sectors on our industries overview.
Tell us about your buildings, your clinical systems and where coverage fails today. Our India-based engineers will propose a design, confirm specifications in writing and send datasheets, usually within one business day.
The questions hospital IT, biomedical engineering and procurement teams put to us most often.
Yes, and it is the normal design. Guest access runs on its own VLAN enforced in NetForce switching hardware, with policy at the NetGuard controller permitting internet egress only. There is no route from a visitor device to a clinical or biomedical segment because no such route is configured. Client isolation is also enabled on the guest profile so guest devices cannot see one another.
Phased installation, area by area, alongside the existing network, with validation after each phase. There is no dependency on a maintenance window. Where a ward is already being refurbished, we align the network phase to that programme so that one disruption covers both.
Roaming continuity across the estate is a primary design objective, since a dropped session interrupts a clinical workflow rather than merely annoying a user. Cells are deliberately overlapped along circulation routes and transmit power is tuned for clean handover. Because access points, switching and controller come from one OEM on one firmware cycle, roaming behaviour stays consistent across buildings.
Shielded rooms create predictable dead zones, and we treat them as planned rather than as faults. The design problem is the threshold and the adjacent corridor, where a client can otherwise cling to a weak signal instead of handing over. These areas are surveyed specifically and covered from the corridor side.
Yes, and we recommend it. Biomedical devices behave differently from clinical applications — long lifecycles, vendor-controlled firmware, limited patching — so they get their own segment with a tightly drawn destination policy, usually with no internet access at all unless the equipment vendor genuinely requires it.
Indian institutional buyers increasingly require MTCTE, TEC and WPC status, and it is often a tender condition. Our advice for any vendor, ourselves included, is to ask for written per-model confirmation covering the exact SKUs in the bill of materials rather than relying on a general website statement. We will provide that confirmation in writing for the models proposed in your design. See our certifications page for the documentation we can supply.
That is the usual case. NetCloud Central gives one console across every block and, for hospital groups, across every site — with zero-touch provisioning for new wards, alerting that points at a device rather than producing a flood of symptoms, and remote change so that troubleshooting does not begin with a walk to another building.
Floor plans or a site layout, expected concurrent devices at the busiest hour, the traffic classes that must stay separate and any audit requirement attached to them, details of existing switching and cabling, and where coverage fails today. From that we produce a design document you can tender against. Send us the details and we will normally respond within one business day.