Health Tech Device Firmware

Custom Firmware for a Wearable Patient Monitoring Device

Connected medical devices represent one of the most demanding domains in embedded firmware engineering. The convergence of real-time biosensor processing, ultra-low power operation, wireless connectivity, and regulatory compliance creates an engineering challenge that exceeds what most software teams — even talented ones — are equipped to handle without specialized experience. When a Series B health tech startup approached ESS ENN Associates to develop the firmware for their continuous patient monitoring wearable, the stakes were exceptionally high: patient safety, FDA regulatory approval, and the company's commercial viability all depended on getting the firmware architecture right from the foundation up.

This case study documents how our embedded systems engineering team delivered clinical-grade firmware that exceeded every performance target and passed IEC 62304 regulatory audit on the first attempt.

The Client

Our client is a Series B health tech startup that had secured $18 million in venture funding to develop a continuous patient monitoring wearable device. The device is designed for deployment in hospital wards, post-surgical recovery units, and home healthcare settings, providing continuous measurement of five vital signs: heart rate, blood oxygen saturation (SpO2), skin temperature, respiratory rate, and motion with fall detection. The company had assembled a strong team of biomedical engineers and clinical scientists but lacked the deep embedded firmware expertise needed to transform their sensor hardware prototype into a production-ready, FDA-approvable medical device.

The founding team had previously attempted firmware development with a general-purpose embedded consultancy, but the resulting code failed to meet power consumption targets by a factor of three and did not incorporate the IEC 62304 software lifecycle processes required for FDA submission. They needed a partner who understood both the embedded engineering and the regulatory dimensions of medical device firmware development.

The Challenge

The technical requirements for this device pushed the boundaries of what is achievable on a battery-powered wearable platform. Every design decision involved difficult tradeoffs between competing constraints. The core requirements included:

• Real-time processing of 5 biosensors at 250Hz: The photoplethysmography (PPG) sensor, accelerometer, gyroscope, temperature sensor, and impedance pneumography circuit all required simultaneous sampling at 250Hz. The raw data stream totaled approximately 15,000 samples per second, each requiring filtering, feature extraction, and vital sign computation within the same sampling window to avoid data loss.
• 72-hour battery life on a 350mAh cell: The device's form factor — a wrist-worn unit slightly larger than a fitness tracker — constrained the battery to a 350mAh lithium-polymer cell. Achieving 72 continuous hours of operation required an average system current draw of under 4.9mA, including all sensor acquisition, processing, BLE communication, and display updates.
• BLE 5.3 connectivity with reliable streaming: The device needed to maintain a continuous data stream to both an iOS/Android companion application and a hospital BLE gateway. The connection had to survive the RF-hostile environment of a hospital ward (with Wi-Fi access points, other BLE devices, and microwave ovens creating interference) while maintaining data integrity for clinical-grade vital sign records.
• IEC 62304 Class B compliance: As a medical device with potential to contribute to hazardous situations through software malfunction, the firmware required development under an IEC 62304 Class B software lifecycle. This mandated formal requirements traceability, architectural documentation, unit testing of all safety-critical modules, integration testing, and a complete risk management file per ISO 14971.
• Sub-500ms alarm latency: When any vital sign breached a clinically significant threshold (e.g., SpO2 dropping below 90%, heart rate exceeding 150 BPM), the device needed to generate both a local haptic/audible alarm and transmit an alert to the monitoring gateway within 500 milliseconds. This required deterministic real-time processing with guaranteed worst-case execution times.
• Secure OTA firmware updates: Hospital IT departments require the ability to update device firmware without physical access to each unit. The OTA mechanism needed to implement secure boot, cryptographic signature verification, and A/B partition rollback protection to ensure that a failed update could never leave a device in an unbootable state.
• Extended operating temperature range: The device needed to operate reliably from -10°C to +50°C to support ambulance transport, outdoor patient transfer, and deployment in regions without climate-controlled healthcare facilities.

Our Approach

ESS ENN Associates assembled a specialized team of 4 firmware engineers and 1 regulatory compliance specialist for a 20-week engagement. Our approach was designed to address both the technical and regulatory dimensions simultaneously, recognizing that in medical device development, these concerns are inseparable. Here is how we structured the project:

• Dual-core architecture on Nordic nRF5340: We selected the Nordic nRF5340 SoC for its dual ARM Cortex-M33 architecture, which provided clean separation between the network core (dedicated to BLE stack operations) and the application core (dedicated to sensor processing and vital sign algorithms). This architectural separation was also beneficial from a regulatory perspective, as it allowed us to classify the BLE stack as SOUP (Software of Unknown Provenance) and isolate it from the safety-critical application code.
• FreeRTOS with formal task scheduling verification: We deployed FreeRTOS on the application core with a carefully designed task architecture. Critical tasks (sensor acquisition, alarm evaluation) were assigned the highest priorities with verified worst-case execution times. We used formal schedulability analysis (Rate Monotonic Analysis) to mathematically prove that all deadlines would be met under worst-case conditions, rather than relying on empirical testing alone.
• Custom DSP pipeline for vital sign extraction: Rather than relying on vendor-provided algorithm libraries — which typically prioritize general-purpose accuracy over power efficiency — we developed a custom digital signal processing pipeline optimized for the specific sensor hardware and clinical accuracy requirements of this device. This allowed us to aggressively optimize computational complexity while maintaining clinical-grade accuracy.
• IEC 62304 compliant software lifecycle: From the first line of code, every development activity was conducted within an IEC 62304 Class B framework. This included formal software requirements specifications (SRS), software architecture documents (SAD), detailed design specifications, unit test plans with full requirements traceability, and integration test protocols. Our regulatory compliance specialist worked alongside the firmware engineers throughout the engagement, ensuring that compliance artifacts were generated as a natural byproduct of the development process rather than retrofitted after the fact.
• Power profiling with micro-ampere precision: We used the Nordic Power Profiler Kit II for continuous power measurement throughout development. Every firmware feature was profiled at the micro-ampere level, and power regression testing was incorporated into the CI pipeline to ensure that new code commits did not introduce power consumption regressions.

Technical Implementation

The firmware architecture comprised several interconnected subsystems, each presenting unique engineering challenges. The following sections detail the most significant technical implementations:

Sensor Fusion and Signal Processing: The sensor subsystem integrated three primary ICs communicating over I2C and SPI buses: the MAX30102 PPG sensor (heart rate and SpO2), the LSM6DSO 6-axis IMU (accelerometer and gyroscope for motion, respiratory rate, and fall detection), and the TMP117 high-accuracy digital temperature sensor. Raw sensor data was processed through a multi-stage digital filter chain. The PPG signal first passed through a 4th-order Butterworth bandpass filter (0.5Hz – 5Hz) to isolate the cardiac waveform from DC offset and high-frequency noise. An adaptive noise cancellation stage then used the accelerometer data as a reference signal to remove motion artifacts — a critical requirement for a wrist-worn device where arm movement constantly introduces noise into the optical measurement. Finally, a peak detection algorithm with adaptive thresholding extracted inter-beat intervals for heart rate computation and performed ratio-of-ratios analysis for SpO2 estimation.

BLE Stack and Connectivity: The BLE implementation used a custom GATT profile designed to minimize connection overhead while maximizing data throughput. We configured a 20ms connection interval with Data Length Extension (DLE) enabled and PHY 2M selected for the data link layer, achieving a sustained application-layer throughput of 48 KB/s — sufficient to stream all vital sign data plus diagnostic metadata in real time. Connection parameter negotiation was implemented to dynamically adjust the connection interval based on data transmission requirements: during active streaming, the 20ms interval provided low latency; during idle periods, the interval was extended to 500ms to conserve battery. The BLE stack also implemented connection supervision timeout handling with automatic reconnection, ensuring that momentary RF interference did not result in permanent data loss.

Power Management Architecture: Achieving 72-hour battery life required a holistic power management strategy touching every subsystem. The firmware implemented dynamic voltage scaling on the application core, reducing the operating frequency from 128MHz to 64MHz during periods when the DSP pipeline had sufficient margin. Sensor duty cycling reduced the PPG LED drive current by 60% when motion artifacts rendered high-resolution optical measurements unreliable — rather than wasting power on data that would be discarded by the noise cancellation stage. BLE connection parameter negotiation, as described above, provided additional savings during idle periods. The aggregate effect of these optimizations was an average system current draw of 4.1mA, providing a calculated battery life of 85 hours on a full charge. However, accounting for battery aging, temperature derating, and a 10% safety margin, we conservatively specified the user-facing battery life as 78 hours.

Secure Boot and OTA Update System: The secure boot chain implemented a hardware-anchored Root of Trust using the nRF5340's built-in key storage. On every boot, the bootloader verified the cryptographic signature (ECDSA P-256) of the application firmware image before transferring execution. The OTA update system used an A/B partition scheme: new firmware images were downloaded to the inactive partition, verified, and then atomically swapped with the active partition on the next reboot. If the new firmware failed to boot successfully (detected by a watchdog-monitored health check within the first 60 seconds of operation), the bootloader automatically rolled back to the previous known-good image. This mechanism ensured that a corrupted or incompatible firmware update could never render a device permanently unbootable — a critical safety requirement for a medical device deployed in clinical settings.

Safety and Fault Tolerance: The firmware incorporated multiple layers of fault detection and graceful degradation. A hardware watchdog timer with a 2-second timeout ensured that any firmware hang would result in a controlled reset rather than silent failure. Brown-out detection circuitry monitored battery voltage and initiated a controlled shutdown sequence when the voltage dropped below 3.0V, ensuring that vital sign data buffered in RAM was safely committed to flash before power was lost. When individual sensors failed or produced implausible readings, the system entered a graceful degradation mode — continuing to report data from functioning sensors while flagging the failed channel with a quality indicator, rather than shutting down entirely. All safety-critical code paths were developed in compliance with MISRA C:2012 guidelines, with deviations documented and justified through formal risk assessment.

Results & Impact

The 20-week engagement delivered a production-ready firmware that exceeded every technical specification and satisfied all regulatory requirements. The following results were validated through extensive bench testing, clinical comparison studies, and regulatory review:

• 78-hour battery life achieved: The device exceeded the 72-hour battery life target by 8%, providing 78 hours of continuous operation on a full charge under typical clinical usage conditions. This margin provides comfortable headroom for battery degradation over the device's expected 2-year service life.
• Clinical-grade sensor accuracy: Heart rate measurement accuracy of ±1 BPM (validated against 3-lead ECG reference) and SpO2 accuracy of ±2% (validated against Masimo pulse oximetry reference) met or exceeded FDA requirements for the intended use classification. Temperature accuracy of ±0.1°C and respiratory rate accuracy of ±1 breath per minute also met clinical specifications.
• 48 KB/s sustained BLE throughput: The custom GATT profile achieved 48 KB/s sustained application-layer throughput with zero packet loss at distances up to 10 meters in a hospital ward environment with active Wi-Fi interference. This throughput was sufficient to stream all vital sign channels plus raw waveform data for clinical analysis.
• 180ms average alarm latency: Critical alarm generation and transmission averaged 180 milliseconds from threshold breach detection to gateway notification — well within the 500ms requirement and fast enough for clinical intervention in acute scenarios.
• First-attempt IEC 62304 audit pass: The software lifecycle documentation, requirements traceability matrix, risk management file, and test evidence package passed the IEC 62304 Class B compliance audit conducted by the client's notified body assessor on the first submission. This is a notable achievement given that first-attempt pass rates for IEC 62304 audits are estimated at under 40% industry-wide.
• Favorable FDA 510(k) pre-submission feedback: The FDA pre-submission meeting resulted in favorable feedback on the software documentation package, with the reviewer noting the thoroughness of the software architecture documentation and the completeness of the verification and validation evidence. The client's regulatory affairs team reported that the firmware documentation was the strongest section of the overall submission package.
• 100% OTA update reliability: Over 2,000 OTA update test cycles — including simulated power failures during update, corrupted firmware images, and network disconnections mid-transfer — the A/B partition scheme achieved a 100% success rate with zero instances of device bricking.
• 99.2% manufacturing yield: The first-pass manufacturing yield of 99.2% significantly exceeded the client's target of 95%, reducing per-unit manufacturing cost and accelerating production ramp-up timelines.

Beyond the technical deliverables, the engagement also included comprehensive knowledge transfer to the client's growing internal firmware team. We delivered detailed architectural documentation, code review guidelines specific to IEC 62304 compliance, and a series of training sessions on FreeRTOS task design patterns, BLE stack optimization, and power profiling methodologies. This knowledge transfer positioned the client to maintain and extend the firmware independently for subsequent product revisions.

Key Takeaways

This engagement yielded several insights that are broadly applicable to medical device firmware development and product engineering projects in regulated industries:

• IEC 62304 compliance must be planned from day one: Attempting to retrofit regulatory compliance onto firmware that was developed without lifecycle controls is vastly more expensive and time-consuming than building compliance in from the start. The requirements traceability matrix, in particular, becomes exponentially more difficult to construct retroactively as the codebase grows. Our experience shows that planning for IEC 62304 from project inception adds approximately 15-20% to the initial development effort but saves 3-5x that amount compared to retroactive compliance efforts.
• Power optimization requires continuous measurement, not datasheet estimates: Semiconductor datasheets provide typical current consumption figures that rarely match real-world application behavior. The actual power consumption of the nRF5340 in our application differed from datasheet projections by 25-40% depending on the operating mode, due to variations in peripheral usage patterns, memory access patterns, and RF transmission duty cycles. Continuous power profiling integrated into the CI pipeline catches regressions early and ensures that power budgets remain on track throughout development.
• BLE connection parameters dramatically affect both throughput and battery life: The difference between a well-optimized and poorly configured BLE connection can be a factor of 10x in both data throughput and power consumption. Dynamic connection parameter negotiation — adjusting connection interval, slave latency, and PHY selection based on application state — is essential for devices that must balance high-throughput streaming with long battery life.
• Sensor fusion algorithms require clinical validation: Algorithm accuracy measured against synthetic test signals or consumer-grade reference devices is not sufficient for medical-grade claims. Our heart rate and SpO2 algorithms were validated against gold-standard clinical reference devices (3-lead ECG and Masimo pulse oximetry) across diverse patient populations including variations in skin tone, age, and physiological conditions such as arrhythmia and low perfusion. Without this level of clinical validation, FDA reviewers will not accept accuracy claims.
• Secure boot and OTA are non-negotiable for connected medical devices: Regulatory bodies increasingly scrutinize cybersecurity aspects of connected medical devices. A secure boot chain with hardware-anchored Root of Trust and a robust OTA update mechanism with rollback protection are baseline requirements, not optional enhancements. The FDA's premarket cybersecurity guidance explicitly calls out these capabilities as expected elements of a connected medical device's security architecture.

If you are developing a medical device, wearable, or health tech product and need firmware engineering expertise that spans both the technical and regulatory dimensions, our IoT & embedded systems and product engineering teams are ready to help. Reach out to discuss how we can accelerate your path from prototype to FDA-ready production firmware.