Bluetooth and Wireless in a Medical Device

Adding Bluetooth to a medical device looks like a two-week firmware task. A module, a GATT service, an app that shows the readings. Teams budget it accordingly, then discover the wireless link has pulled in a coexistence test plan, an FCC authorization, a cybersecurity package, several new hazards in the risk file, and questions about what happens when the connection drops at the wrong moment. None of it is unmanageable; all of it is expensive to retrofit.

The decision that governs everything: data or control

Before anything else, answer this question and write the answer into the design inputs: is the wireless link carrying information, or is it carrying authority?

A BLE link that ships stored readings to a phone for the user to look at later is a data link. If it fails, nothing happens to the patient — the data arrives later, or the user syncs again. A BLE link that lets a phone start an infusion, change a stimulation level, silence an alarm, or deliver a therapy is a control link. If it fails, is delayed, or is spoofed, a patient can be harmed.

These are different products from a regulatory standpoint even with identical radios. A control link makes the wireless subsystem safety-critical, which means:

• Loss of connection becomes a hazardous situation requiring a defined safe state, not an error message.
• Latency has to be bounded and verified, and BLE is not a deterministic transport — you cannot promise a delivery time, only a probability.
• Authentication and integrity become safety controls, not just privacy features.
• The device must remain safe standalone. A device that cannot be stopped without the phone is a design nobody should ship.

The near-universal correct answer for a first product is: keep therapy control on the device, use wireless for data and configuration only, and require a confirmed local action for anything that changes what the device does to a person. This one choice removes most of the regulatory weight of the radio.

Wireless coexistence: the test teams forget to budget

Electromagnetic compatibility testing proves your device tolerates and does not create general interference. That is EMC testing under IEC 60601-1-2, and it is necessary but not sufficient for a device with a radio.

Coexistence is a separate question: does your device still perform its intended function in a real environment full of other radios in the same band? A hospital room holds Wi-Fi access points, dozens of BLE peripherals, staff phones, and telemetry, all sharing 2.4 GHz. The recognized evaluation method is AAMI TIR69, and reviewers commonly expect a coexistence assessment.

The assessment typically involves:

• Defining the intended use environment — home, ambulance, clinic, or hospital ward each carry different RF congestion.
• Stating the functional wireless performance you need as a measurable requirement: throughput, packet delivery ratio, maximum acceptable gap between transmissions, reconnection time.
• Testing against controlled interferers at defined signal-to-interference ratios and separation distances, showing essential performance is maintained.
• Feeding results back into the risk file — what the device does when the link degrades, and whether that is safe.

Budget a few thousand to low tens of thousands of dollars and several weeks of lab time. The cheapest move is to design for it: choose a protocol with adaptive frequency hopping, plan for retries and buffering, and never make essential performance depend on a packet arriving on schedule.

FCC authorization runs in parallel with FDA

These are separate agencies with separate processes, and one does not substitute for the other. Any intentional radiator sold in the US needs FCC equipment authorization, generally certification through a Telecommunication Certification Body, with testing at an accredited lab.

The practical decision is module versus chip-down design.

For a first medical device, use a pre-certified module almost every time. The grant conditions are strict — antenna type and gain, trace layout, enclosure — and violating them silently voids the approval, so read the integration guide as a specification. The process detail is in FCC certification for electronic products.

The antenna is the part that most often forces a re-spin, because it interacts with the enclosure, the battery, and the human body — tissue detunes antennas significantly, which matters enormously for wearables and implantables. Get the antenna placement right in the mechanical concept, not after; see antenna design for wireless products.

Wireless in the risk file

Every wireless feature adds hazards, and they need to be in your hazard analysis with defined controls. Under ISO 14971, the ones that come up in nearly every connected device review are:

• Loss of connectivity. Defined safe state, local buffering, user notification that data is not being transmitted.
• Data corruption in transit. Integrity checking above the transport layer, not reliance on BLE's own CRC alone.
• Wrong device pairing. A patient connected to the neighbor's monitor is a classic and serious failure. Bind identity cryptographically and display a confirmable identifier to the user during pairing.
• Delayed data interpreted as current. Timestamp everything at the source, and make the app display data age explicitly.
• Unauthorized access or command injection. Authentication and encryption, treated as risk controls.
• Battery drain from radio activity. A monitor that dies early because of aggressive advertising intervals has failed its clinical function.

Each needs a verification test that proves the control works — pull the phone out of range mid-session and confirm the documented behavior.

Cybersecurity is now a submission requirement

The FDA expects a cybersecurity package for connected devices, and incomplete packages are a common cause of review deficiencies. Broadly you should plan for a threat model, a software bill of materials covering the BLE stack and every third-party component, a plan for monitoring and patching vulnerabilities across the product's supported life, secure boot and signed firmware updates, and documentation of the security controls and their testing.

The expectations, and how they interact with the submission, are laid out in FDA cybersecurity requirements for connected medical devices. On the link itself, the practical measures are the same ones any serious connected product uses — pairing with man-in-the-middle protection, application-layer encryption so that a compromised phone stack does not expose clinical data, and rotating identifiers so a device does not broadcast a trackable address, all covered in securing the BLE connection. One rule specific to medical: do not implement your own cryptography, and do not rely solely on the transport's security for anything that matters.

Choosing the protocol

BLE is the default for a battery-powered device that talks to a phone, and for good reasons: low power, universal phone support, no infrastructure. Its limits are modest throughput and no guaranteed timing.

Wi-Fi makes sense when the device must reach a server without a phone in the loop, at the cost of power and provisioning complexity — getting a device onto a hospital network is a real usability problem, not a footnote. Cellular suits deployments with no reliable local network and no one to configure anything; proprietary sub-GHz links buy range and a quieter band but need your own gateway.

Whatever you choose, the firmware side deserves the same design discipline as the hardware — power budget, connection parameters, service structure, and update path — as covered in BLE firmware development.

Projects House designs connected medical devices with the radio, the coexistence plan, the FCC route, and the risk controls settled before layout starts. Tell us what your device needs to transmit through the contact form.