Wearable health monitoring is transforming remote patient care, enabling continuous tracking of vitals beyond clinical boundaries. They are moving care from the hospital to the patient’s everyday life, providing continuous measurement of heart rate, SpO₂, temperature, ECG and motion, delivering richer diagnostic data than sporadic spot checks. This continual measurement helps detect health condition deterioration earlier, leading to better patient care. Remote patient monitoring and early-warning capabilities improve therapy adherence and increase patient safety.

These benefits are driving the strong growth in the wearable medical device market. Market studies indicate a double-digit CAGR through to 2030, with a market value surpassing $150bn. Competition comes from traditional med-tech companies, consumer electronics giants and specialised startups. In such a landscape, the fastest teams that can implement, certify and iterate products quickly gain a decisive advantage; in this sector, time-to-market and predictable development are business-critical.

Engineering challenges

Engineering teams face a combination of technical, regulatory and commercial hurdles when developing connected wearables. Among the most critical aspects are the time-to-market, regulation and certification, power consumption, engineering know-how for fast product development, product size, and integration complexity.

Building reliable, secure and power-efficient connected wearable systems remains an engineering marathon, fraught with technical and commercial pitfalls. From battery drain and regulatory compliance to BLE know-how gaps, security risks and drawn-out development cycles, the engineering hurdles can be sizeable. Thus, many companies like Würth Elektronik dedicate their engineering know-how to developing pre-built, standards-compliant firmware, creating a shortcut to a successful, ready-for-market wearable medical devices. By reusing certified hardware, proven firmware and ready-to-use SDKs, engineering teams can focus on clinical value and user experience instead of the wireless maze, in many cases achieving up to 75% faster integration and a much smoother path to regulatory approval.

For medical IoT applications based around Bluetooth, designing a custom Bluetooth LE stack, GATT (Generic Attribute Profile), pairing logic and mobile app integration often stretches over a year. Devices must be small, comfortable and safe, with a tight energy budget on a single coin cell or compact LiPo battery. Continuous or near-continuous data streaming drains small batteries quickly, and, yet, multi-day run times are mandatory for user acceptance.

Then there are the engineering challenges associated with multiple sensors on SPI/I²C buses, timing constraints and real-time data handling adding software complexity on the host microcontroller, connectivity issues, and potential security weaknesses. In addition, engineering teams must also grapple with regulation and certification based around the RF parts, as well as with medical approvals that require repeatable test setups, stable firmware and clear documentation.

All these factors result in increased risk and prolonged development, and can delay or even block regulatory submissions.

Pragmatic solutions: Proteus-IV and Ophelia-IV radio modules

Würth Elektronik is addressing these challenges with two module families: Ophelia-IV and Proteus-IV. Ophelia-IV is a highly integrated Nordic nRF54L15-based module for engineers who want to develop their own firmware using nRF Connect SDK and Zephyr RTOS. This module targets advanced applications and provides customisation. Proteus-IV, on the other hand, is a Bluetooth LE 6.0 module with pre-installed, pre-qualified SPP-like firmware that exposes a simple UART-based interface to the host MCU. With this module no Bluetooth firmware development is required.

Both modules fit in a WLCSP package (12 x 8mm²), with output power to 8dBm, 1.5MB Flash and 256KB RAM. Supported data rates include Bluetooth 6.0 (2Mbps, 1Mbps, 50kbps and 125kbps), IEEE 802.15.4-2020 (250kbps) and proprietary 2.4GHz (4Mbps, 2Mbps and 1Mbps). They also feature options for integrated or external antennas and qualification for CE, FCC, IC and Bluetooth. Proteus-IV in particular is designed as a plug-in communications layer: the host MCU sends data over UART, and the module transparently handles the connection, pairing, encryption and data transport. For new medical and health wearables that need robust, secure and efficient data streaming to a mobile app or gateway, Proteus-IV is usually the fastest and lowest risk route to a market-ready design.

System Integration with Proteus-IV

A typical sensor architecture for a wearable patch or wrist device looks is shown in the figure. There are could be one or more medical sensors (ECG, PPG, temperature, IMU, etc.), which connect via SPI or I²C to a host microcontroller, which handles sensor configuration, basic preprocessing and measurement data aggregation. The resulting data packets are then sent over an UART to the Proteus-IV module, which forwards it via its SPP-like BLE profile to a smartphone or tablet application. The app may also visualise the data, upload it to the cloud or connect it to a clinical back end.

The communication can bidirectional; i.e., the app can send configuration commands such as sampling rate, measurement mode or thresholds back through Proteus-IV to the host MCU. This architecture cleanly separates sensor and application logic from the wireless stack.

To simplify integration on the host MCU, Würth Elektronik provides the open-source Wireless Connectivity SDK with drivers, and examples in C. The SDK abstracts the UART protocol and module control into high-level functions. It also provides the features of the radio modules as functions, so that its integration is done in a few steps:

1. First, the GPIOs and UART of the host MCU must be defined. Here the available pins of the host MCU are chosen to be used for GPIO and UART purposes:

/* definition of the application GPIOs connected to the Proteus-IV */
ProteusIV_Pins_t ProteusIV_pins = {
.ProteusIV_Pin_Reset = WE_PIN((void*)&PIN(GPIOA, GPIO_PIN_10)),
.ProteusIV_Pin_Mode0 = WE_PIN((void*)&PIN(GPIOA, GPIO_PIN_7)),
.ProteusIV_Pin_Mode1 = WE_PIN((void*)&PIN(GPIOA, GPIO_PIN_8)),
.ProteusIV_Pin_Led1 = WE_PIN((void*)&PIN(GPIOB, GPIO_PIN_9)),
.ProteusIV_UART_Enable = WE_PIN((void*)&PIN(GPIOA, GPIO_PIN_0)),
};

/* definition of the UART connected to the Proteus-IV */
WE_UART_t ProteusIV_uart = {
.baudrate = 115200,
.flowControl = WE_FlowControl_RTSAndCTS,
.parity = WE_Parity_None,
.uartInit = WE_UART1_Init,
.uartDeinit = WE_UART1_DeInit,
.uartTransmit = WE_UART1_Transmit,
};

2. Next, the callback functions must be defined, to inform the application about events sent from the module to the host. This includes events for connection and security setup, as well as data reception:

/* definition of the callbacks */
ProteusIV_CallbackConfig_t callbackConfig = {
.rxCb = RxCallback,
.connectCb = ConnectCallback,
.maxPayloadCb = MaxPayloadCallback,
.disconnectCb = DisconnectCallback,
.linkOpenCb = LinkOpenCallback,
.securityCb = SecurityCallback,
.passkeyCb = PasskeyCallback,
.displayPasskeyCb = DisplayPasskeyCallback,
.phyUpdateCb = PhyUpdateCallback,
.scanCb = ScanCallback,
};

3. To start the Proteus-IV radio module in the chosen operation mode, the ProteusIV_Init function must be called:

if (false == ProteusIV_Init(&ProteusIV_uart, &ProteusIV_pins, ProteusIV_OperationMode_CommandMode, callbackConfig))
{
WE_APP_PRINT(“Initialisation error\r\n”);
return;
}

4. Data is then fetched from the sensors and sent via the Proteus-IV to the mobile phone app, once the radio link is open:

if (I2C_getData(data) && ProteusIV_connection_list[conn_ID].is_linkopen)
{
ProteusIV_Transmit(conn_ID, data, MIN(sizeof(data), ProteusIV_connection_list[conn_ID].max_payload));
}

With this module, the actual firmware work on the MCU side remains focused on sensor handling and data formatting, not on implementing a Bluetooth LE stack.

Its faster with pre-certified modules

Using a pre-certified module with SPP-like BLE firmware has a measurable impact on both engineering and business metrics. Typical values for a wearable device project include integration time of 1-2 weeks at application level, compared with 6-8 weeks for a custom GATT-based solution.

The code size of the application firmware stays below a few tens of kilobytes when the BLE stack is offloaded to the module, which simplifies maintenance.

In addition, RF-related effort, certification time and costs are significantly reduced by leveraging module certifications – this is particularly valuable to companies which are entering new medical segments or expanding existing product lines.

Future trends

Wearable health monitoring combines strict medical expectations with consumer-level usability demands. Teams that try to reinvent BLE connectivity and RF design from scratch often lose precious months and undertake risks that could be considered unnecessary.

Pre-certified radio modules with proven SPP-like BLE firmware decouple sensor and algorithm innovation from wireless complexity. Modules like Proteus-IV and Ophelia-IV form a scaleable platform for developing robust, safe and secure medical and health wearables. And as regulatory and cybersecurity requirements continue to tighten, modular, standards-based connectivity will become an even more important foundation for safe, efficient and innovative applications with wireless connectivity like healthcare products.

By Adithya Madanahalli, IoT Engineer in the Wireless Connectivity and Sensors unit at Würth Elektronik eiSos, and Matthias Hauser, a Software Engineer, at Würth Elektronik