Edge versus cloud, in founder language
Edge computing means running logic on the device or a nearby gateway, not only in a distant data center. In medtech, edge processing can reduce latency and keep limited data off shared networks, but it also shifts complexity into firmware, OTA update policy, and local storage. Cloud-heavy designs can be simpler to iterate in development yet fragile when a ward Wi-Fi is saturated or a patient is off-network at home. There is no universal winner: the right split follows workflow risk, data governance, and what your team can operate safely for years.
What this page helps you decide
This page helps teams decide what should happen on the device, what should happen in the cloud, and how the product behaves when connectivity is weak. Firmware, wireless protocols, offline behavior, and updates are product reliability decisions.
Use it before committing to BLE, Wi-Fi, cellular, NFC, edge processing, or OTA update assumptions.
Choosing a connectivity path
Your radio choice is a product and security choice. Bluetooth Low Energy (BLE) fits short-range paired accessories and many wearable paths; it is not a substitute for a full network stack when you need high throughput or hospital-wide reach. Wi-Fi is attractive where IT can onboard and maintain devices, but enterprise Wi-Fi (portals, certificates, firewalls) can be harder than “works on my home router.” Cellular helps distributed or mobile use and avoids local Wi-Fi battles, at the cost of subscriptions, power, and variable indoor coverage. NFC is useful for tap-to-pair or very short data bursts; LoRa and similar low-power wide-area options appear in asset tracking and remote monitoring scenarios but come with their own rate and protocol limits.
Whatever you pick, design for an offline-first or “degraded but safe” experience when the link drops mid-task, because it will happen.
Connectivity decision matrix
| Option | Good fit | Tradeoff |
|---|---|---|
| BLE | Short-range paired devices, low data rates | Limited bandwidth, pairing and coexistence with other radios |
| Wi-Fi | Clinical sites with managed infrastructure | Security, configuration, and site-specific network rules |
| Cellular | Distributed home or field use | Ongoing cost, power, and variable indoor signal |
| NFC / LoRa (examples) | Pairing, low-bit-rate telemetry, or long-range low-power | Not general-purpose: match protocol to a narrow use case |
Firmware and OTA in the real world
Updates are a lifeline and a risk. Good practice pairs cryptographic signing, staged rollouts, and verified rollback with clear ownership under change control. Your checklist should be enforceable, not aspirational. Interrupted updates, partial writes, and power loss during OTA are not rare edge cases; they are expected field conditions. Battery and thermal impact of new firmware can change clinical behavior even when features look identical on a slide.
- Require cryptographic signing, source authenticity, and reject unsigned images.
- Stage rollout (cohorts, canaries) with metrics that catch regressions before full fleet exposure.
- Define safe rollback behavior and user-visible state when a rollback occurs.
- Document battery, thermal, and latency impact of each release class.
- Align OTA event logging with security monitoring and postmarket expectations.
Further reading (learning only)
Use these to frame discussions with engineering and security. Architecture and threat assumptions must be validated for your specific device class and market.
- Bluetooth technology overview — consumer-facing overview of tradeoffs in Bluetooth product design.
- NIST CSRC — publications — U.S. National Institute of Standards and Technology Computer Security Resource Center; search for device and firmware security guidance relevant to your architecture.
- U.S. FDA — medical device cybersecurity — regulatory expectations for connected devices, complementary to threat modeling in this track.
- NIST CSRC — U.S. National Institute of Standards and Technology Computer Security Resource Center; search for IoT and firmware update topics relevant to your threat model.
Practical next step
Write the offline behavior for one critical workflow: what the device stores, what the app shows, what syncs later, and what the user should do if sync fails.
- Template or worksheet: architecture review checklist.
- Glossary terms: firmware, OTA update, offline-first.
- Pathway links: Reliability and power, Secure updates.