How to correctly setup the wireless network in a medical office

Medical offices often have the same problem as all other offices, the wireless signal doesn’t always cover the entire office, and if it does the speed in some of the patient rooms are very slow.  Luckily we have a few solutions to have your wireless signal with good speed all over the office!

Quick overview

Here’s a quick overview of what you should do to extend your office network with a second, third or more access points:

To extend your office network:

  • Connect two, three or more access points to the same network
  • Make sure that there is only 1 DHCP server in the network
  • Use the same wireless network name (SSID) for all AP’s
  • Use the same password and encryption settings for both AP’s
  • Change the channel of each AP, remember  not to overlap
  • Add the MAC address of each wireless  device in the office to all AP’s
  • Enjoy!

Full Instructions

The basic diference between the wireless network at a medical office and any other network, is that it is required by HIPAA regulation to have the wireless network protected by an access list.  The access list contains all the MAC addresses of each wireless card that will connect to the wireless network.

Most offices are secure enough but just having a strong password.  But if you want the added security of having an access list read below and I’ll explain where and how this is done.


By default, any wireless laptop, PC, tablet or phone that is configured with the correct SSID will be allowed access to your wireless network. For increased security, you need to restrict access to the wireless network to allow only specific devices based on their MAC addresses. Usually on the Wireless Settings screen, click the Setup Access List button to display the Wireless Access List screen.

An easy way to get the MAC address of each device that connects to your router or AP is by looking at the connected devices.

Consult you router or Access Point documentation on where to find this.


Multiple access points should share the same SSID. They must have exactly the same security settings (same password, exact same mode, i.e. WPA2-PSK Personal) for clients to be able to automatically roam between APs.

Multiple bands (2.4 GHz and 5 GHz) should also have the same SSID. Don’t put 5 GHz on its own SSID.

If you use one single SSID globally, clients will choose the best AP and channel to connect to automatically. If you use separate SSIDs but they’re within overlapping coverage range, users need to connect and disconnect manually. This is a bad user experience and will often lead to laptop users remaining marginally connected to an AP they’re barely within range of.


Automatic Wi-Fi channel selection is problematic because the AP can change channels whenever it likes, which causes a global disruption in service for connected clients.

Statically assign different access points to different channels.

Use a an app on your phone or laptop to identify channels that aren’t in use by your next-door neighbors to avoid packet collisions and re transmits.

Use non-overlapping channels. On 2.4 GHz, this means you should only choose channels 1, 6, or 11. On 5 GHz, it’s a bit more complicated, but any channel number is OK and non-overlapping if you’re following my advice about 20 MHz bandwidth and avoiding DFS frequencies below.


If you’re in a large office building, force your AP radios to use only 20 MHz bandwidth on both 2.4 GHz and 5 GHz bands. (If you’re in a more suburban or rural setting and have few other transmitters in radio range, you may be able to increase this.)

Wider radio bandwidths of 40, 80, or 160 MHz definitely increase the maximum theoretical throughput — for example if you have only a single client and a single AP in a patch of rural farmland. But in a real-world noisy radio environment, a wider bandwidth also increases the probability of a radio packet loss, because a collision with a competing transmission on any sub-channel corrupts the entire signal — whether due to random noise or interference from another transmitter.

Collisions are incredibly expensive as both transmitters have to back off and retry sending the packet again. In a noisy environment it may take a while before the wider bandwidth channel is entirely clear again, and devices may spend yet more time negotiating their channel bandwidths up and down dynamically.

Another way to think about this is in terms of signal-to-noise ratio (SNR). Using a wider bandwidth spreads the same signal power over a wider slice of spectrum, so there’s lower power spectral density (W/Hz), and higher total noise integrated over the wider frequency band.

Optimize your user experience for minimal packet loss, rather than maximum theoretical throughput.


On the 5 GHz band, there are a set of extra channels which are made available using Dynamic Frequency Selection (DFS). This is a complicated process that involves clients listening for whether weather radars are using those frequencies, and changing channels if they are.

The problem is that, by law, any detected interference must trigger the AP to stop transmitting immediately and go to a listen-only mode to find a new, unused channel. Obviously, this silencing behavior provides for bad user experience.

To compound this problem, DFS channels may not be clearly marked on your AP’s configuration! The macOS Wireless Diagnostics tool shows the DFS status in the Info pane.

In summary, just avoid using channels 52 through 144 on the 5 GHz band.


Don’t let your primary router, and gigabit ethernet switch be located in a cabinet that  can look tempting to use for general office storage. It’s easy to imagine office supplies and extra company swag piling up on top!

Post signs and notify people that this is fragile, important equipment — not a general storage area!


Assign static IPs for infrastructure like access points. This makes them easy to reach when reconfiguration is needed, and avoids them having to pull their own addresses dynamically.  We like to set any equipment on the low end of the IP pool.  For example, and below for routers, access points etc.  On the upper end we add printers, scanners and other devices.  For example, and higher.


If for example you  have a full-time team of 30, plus a rotating staff.  I expect each person to have at least two devices: laptop and phone. That’s 60-80 IPs right off the bat.

Many routers are configured with a fairly small IP pool allocated to DHCP out of the box. This will cause issues if the DHCP pool is exhausted. I recommend you  configure your primary router to reserve 200 IPs for DHCP, leaving us about ~50 for static IP assignments. We use a 1-day DHCP lease time so unused addresses can be returned to the pool fairly quickly, while not requiring DHCP renewals during the workday.

If you have multiple APs, make sure only a single device (usually your primary router which is doing NAT) is configured as a DHCP server.


When wired or wireless clients request an IP address via DHCP, they’re also provided with DNS servers to use.

I use Google’s and in my DHCP server configurations.

Another option is to use your primary router as a caching DNS resolver, and then point all clients to it. On paper this makes a lot of sense as it can locally cache for faster performance. However, the public DNS servers are so fast that I decided to have each client use them directly, avoiding any potential local caching issues.


Our new public IP address doesn’t have our San Francisco location in the GeoIP database — it just says “United States.” I suspect that geographic-based DNS lookups and CDNs are giving us worse-than-optimal performance because of this. We requested a GeoIP database correction, but it hasn’t been accepted yet.

This issue also led to tools like Speedtest connecting to the wrong test servers many states away and severely underestimating performance.


While you may know now the configuration, in the future it may be helpful to have everything labeled.

I like to create a documents detailing configuration settings for all APs and routers, screenshots, static IP assignments, wireless channel map, and ISP support contact info.


For throughput: the Speedtest numbers speak for themselves.  You should see numbers close to what you are quoted from your ISP.

Reliability:  Sooner or later you may have an issue the first few times, but after debugging you will learn to watch out for issues described above (DFS channels, 20 MHz radio bandwidth, and one AP on a non-gigabit ethernet cable).  You will be happy to have a network that is basically trouble-free — i.e. no more complaints from the team!

I highly recommend the High Density Wi-Fi Deployment Guide from Meraki if you’re interested in reading more.

If you’re a software engineer interested in seeing offers from top tech companies that already have working Wireless networks working you should take the Triplebyte quiz — and if you care about compensation, see their software engineer salary data.


WhatsApp Start Live Chat