Wi-Fi
Wi-Fi Design & Engineering For Connected Medical Devices
Wi-Fi puts your device on someone else’s network. We engineer it for the networks it will actually meet.
A Wi-Fi Connected System, Engineered As One.
Where Wi-Fi gets hard
The Network Is the Part You Don't Control.
Every Wi-Fi decision gets tested by a network you didn’t design.
Connectivity Strategy
- Choosing between Wi-Fi, BLE, cellular, or a multi-protocol approach for the use case
- BLE-to-Wi-Fi commissioning architecture is about to lock
- Topology (gateway vs direct-to-cloud) has to be decided before development commits
- One radio may not cover the range, topology, and bandwidth the product needs
- The wireless approach has to fit the power, size, and cost envelope
Feasibility & Risk
- Wi-Fi performance isn’t proven in the RF environment the device will deploy into
- Range, attenuation, and roaming behavior aren’t validated against the real deployment
- Device-to-cloud reliability is unproven against real-time and security demands
- The wireless approach hasn’t been validated before full development commits
- The concept needs proving before major capital goes in
Security Architecture
- The shared-network threat model has to be built into the architecture from the start
- Certificate provisioning and lifecycle have to scale before manufacturing does
- The authentication model has to hold across consumer, institutional, and clinical networks
- 524B documentation needs to be generated during development, not assembled at submission
- Wireless security architecture is being scoped before regulatory expectations are clear
Power Architecture
- Power budgets are being set before Wi-Fi’s real radio cost is modeled
- Sleep and wake architecture is being scoped before the cloud session contract is defined
- BLE and Wi-Fi duty cycles have to be coordinated in the power architecture
- Battery life targets need validation against field-realistic usage before commit
- Provisioning and reconnection power costs weren’t accounted for in the budget
Cloud Architecture
- Cloud protocol choice (MQTT, HTTPS, WebSocket) is being made before the data model is clear
- Session model and reconnection semantics weren’t designed for real-world connectivity gaps
- Offline behavior and data sync have to hold without breaking cloud consistency
- Certificate lifecycle and TLS termination weren’t architected for production scale
- A protocol layer designed for a prototype hasn’t scaled with the product
Provisioning & Onboarding
- Provisioning breaks on networks with non-standard DHCP, ISP proxies, or captive portals
- Network join completes but DNS, clock, or routing keeps the device offline
- Clinical networks require credential management the device wasn’t designed for
- The same device has to provision in both consumer homes and clinical environments
- Users abandon setup because the onboarding flow doesn’t fit their environment
Network Resilience
- Devices lose data or behave unpredictably during network outages
- Connection recovery after interruption requires manual intervention
- Local buffering and retry logic weren’t designed for real network conditions
- Firewall rules and DNS failures block device communication in the field
- Performance degrades when the network is congested or signal is attenuated
Fleet Operations
- OTA firmware updates fail across the fleet because the rollout strategy wasn’t designed for scale
- Devices in the field can’t be diagnosed because remote logging wasn’t built in
- Fleet visibility is limited because device management wasn’t architected for production
- No rollback strategy exists when an update introduces a regression
- Manufacturing provisioning doesn’t scale to the fleet size the product is shipping into
Clinical Deployment
- Clinical engineering surfaces network architecture assumptions that don’t hold
- Hospital IT policies block or restrict device communication
- Device performance degrades in clinical RF environments
- Network segmentation requirements weren’t accounted for during architecture
- Deployment slips when clinical constraints surface late in the program
OUR APPROACH
We Engineer Wi-Fi as a Deployment Problem.
The radio is the easy part. The network it joins is the work.
The Problem
Wi-Fi gets handed off as connectivity. The decisions don't stay there.
When Wi-Fi gets treated as a deliverable, the architecture choices it forces (power, cloud session, security, fleet operations) get made inside other layers, by teams that don’t carry wireless authority. The wireless behavior the product ships is whatever those layers leave behind.
How We Engineer It
So we design for the network before we design the device.
A wireless strategy commits more than the radio. It commits the power architecture feeding the radio, the cloud session running over it, and the security architecture defending it. Those layers get engineered as one because the same engineers build them all.
What this looks like in practice:
- Wireless strategy chosen against the use case and deployment environment, not the protocol the team knows best
- Power architecture modeled against Wi-Fi’s real radio cost in field-realistic usage
- Device-to-cloud protocol designed for the network conditions Wi-Fi will actually encounter in the field
- Wireless security architected against the shared-network threat model and documented for FDA cybersecurity documentation (524B) as the work happens
- Multi-protocol coexistence (BLE plus Wi-Fi) engineered as a single radio architecture
- Fleet operations infrastructure built into the architecture from the start
The Results
The device that works in your lab works on their network.
Early Wi-Fi decisions hold all the way to deployment. The architecture goes to design freeze knowing what the field, the production scale, and the cybersecurity review will test it against, so the program stops relitigating wireless decisions late.
Why teams trust us
The Wi-Fi Work Behind Cleared Medical Devices.
Earned on hospital networks and in commercial buildings where Wi-Fi had to work on the first install.
Connectivity Depth
Hundreds of connected device programs across BLE, Wi-Fi, and cellular.
Fifteen years of wireless engineering have taught us the tradeoffs among them. We know when Wi-Fi is the right choice, when BLE is, and how to make both work in a single connected system.
That same cross-protocol view is why we engineer Wi-Fi knowing how a protocol-level decision moves through firmware, mobile, cloud, and security.
CROSS-LAYER ENGINEERING
Wi-Fi engineered across every layer it reaches.
Wi-Fi shapes firmware, mobile, cloud, security, and the system architecture that holds them together. We build all of those layers, which means Wi-Fi decisions get made with full visibility into what every other layer requires, and the cross-layer problems Wi-Fi creates get resolved by the team that engineered them.
Proven in Regulated Products
Wi-Fi connected medical devices in production, cleared and shipping.
Wi-Fi runs in cleared connected medical devices deployed in clinical environments today. We engineer it to FDA and IEC 62304 from the first architecture decision, with traceability, risk control, and 524B cybersecurity documentation generated as the work happens.
Clinical Deployment
Wi-Fi engineered for the networks hospitals actually run.
Cleared connected medical devices we’ve engineered are running today on hospital networks, through clinical engineering review, MDS2 documentation, and the IT policies institutional environments enforce. That experience shapes how we architect Wi-Fi before clinical engineering ever sees the device.
Wi-Fi Connected Products We’ve Delivered On
Here are a few of the products we’ve supported with Wi-Fi architecture, troubleshooting, and full-system integration.
Smart Privacy Glass on a Scalable Embedded Linux Platform
CLiC™ is Cardinal IG’s smart privacy glass, and after more than ten years of development it entered full-scale production in 2026.
A pane switches from clear to private in under a tenth of a second, with no tint or distortion, and ties into smart home and building control systems.
For a home or a hospital room, that means privacy on command with no blinds or drapes. It also means a window that is now a connected device, one that has to stay secure and keep working for as long as the glass does, and be built the same way for every manufacturer who puts it into a window, glass door, or glass partition.
A Connected Docking Station for Clinical Microneedling Devices
DermapenWorld’s Dp4™ microneedling pens are used in clinics around the world, all kept current through a companion app.
The Dp DOCK™ is where a pen sits between treatments. It syncs the pen to the app, installs firmware updates, watches its battery, and will not let it be stored with a needle cartridge attached.
For a practitioner, that means a pen that is current and ready for the next treatment without anyone thinking about it. It also means a dock that has to work with every version of the pen and app in the field, in a clinic where it will never get a second look.
Next-Generation Remote Management for a Cath Lab Device System
One in four angiography patients has chronic kidney disease, and the contrast dye that makes the procedure possible is hard on the kidneys.
Osprey Medical’s FDA-cleared DyeVert™ PLUS diverts part of the dye before it reaches the patient, cutting the amount delivered by about 40 percent with no loss of image quality, and tracks each patient’s cumulative dose against their kidney function in real time.
For those patients, that means a heart procedure with less risk of kidney injury. It also means a tablet talking wirelessly to bedside devices inside a cath lab, one of the noisiest radio environments in a hospital, where nothing can drop mid-procedure.
A Building Automation Concept Proven in the Real World in Weeks
A smart building startup is developing an automation platform for commercial buildings, one that controls and monitors dense fleets of connected devices across facilities shared by many tenants.
For a building operator, the aim is one system running the connected devices of an entire property. It also means radio working through metal enclosures and motor interference at extreme device density, and a security model that has to hold across every tenant, device, and door it touches.
Smart Privacy Glass on a Scalable Embedded Linux Platform
A Connected Docking Station for Clinical Microneedling Devices
Next-Generation Remote Management for a Cath Lab Device System
A Building Automation Concept Proven in the Real World in Weeks
Smart Privacy Glass on a Scalable Embedded Linux Platform
CLiC™ is Cardinal IG’s smart privacy glass, and after more than ten years of development it entered full-scale production in 2026.
A pane switches from clear to private in under a tenth of a second, with no tint or distortion, and ties into smart home and building control systems.
For a home or a hospital room, that means privacy on command with no blinds or drapes. It also means a window that is now a connected device, one that has to stay secure and keep working for as long as the glass does, and be built the same way for every manufacturer who puts it into a window, glass door, or glass partition.
A Connected Docking Station for Clinical Microneedling Devices
DermapenWorld’s Dp4™ microneedling pens are used in clinics around the world, all kept current through a companion app.
The Dp DOCK™ is where a pen sits between treatments. It syncs the pen to the app, installs firmware updates, watches its battery, and will not let it be stored with a needle cartridge attached.
For a practitioner, that means a pen that is current and ready for the next treatment without anyone thinking about it. It also means a dock that has to work with every version of the pen and app in the field, in a clinic where it will never get a second look.
Next-Generation Remote Management for a Cath Lab Device System
One in four angiography patients has chronic kidney disease, and the contrast dye that makes the procedure possible is hard on the kidneys.
Osprey Medical’s FDA-cleared DyeVert™ PLUS diverts part of the dye before it reaches the patient, cutting the amount delivered by about 40 percent with no loss of image quality, and tracks each patient’s cumulative dose against their kidney function in real time.
For those patients, that means a heart procedure with less risk of kidney injury. It also means a tablet talking wirelessly to bedside devices inside a cath lab, one of the noisiest radio environments in a hospital, where nothing can drop mid-procedure.
A Building Automation Concept Proven in the Real World in Weeks
A smart building startup is developing an automation platform for commercial buildings, one that controls and monitors dense fleets of connected devices across facilities shared by many tenants.
For a building operator, the aim is one system running the connected devices of an entire property. It also means radio working through metal enclosures and motor interference at extreme device density, and a security model that has to hold across every tenant, device, and door it touches.
Ready to get started?
Quick Discovery Call
Team Consultation
