You build an on-device arrhythmia detection system by designing backwards from the constraints of a small medical device: a microcontroller with limited RAM and flash, a strict power budget and continuous ECG sampling, with every detection made on the device, none in the cloud. On-device arrhythmia detection in medical devices is a reliability problem first, an AI problem second.
If you are specifying a wearable or portable cardiac monitor now: decide four things before a model is chosen: which detections must happen on the device with no connection at all; the sampling rate the clinical signal needs and the latency an alert may tolerate; the battery life the use demands; and how the model will be versioned and validated as part of the device software, whose life cycle requirements IEC 62304 defines. Those four answers size the processor, the firmware architecture and the regulatory file. The worked example that follows is an illustration, not a record of one programme; it shows how those four answers interact.
In the worked example that follows, where an on-device arrhythmia detection system is built, innovation was never the headline goal.
Reliability was. The point was not to prove that AI could run on tiny hardware. The problem being solved was far more grounded and urgent:
How do you deliver life-saving cardiac intelligence on a chip with less RAM than a smartwatch face without cloud dependency, without latency, and without failure?
Because in emergency medicine, “almost real time” is still too slow. And “we’ll sync it later” is not an acceptable answer.
Why do cloud-based diagnostics fall short in real care settings?
Cloud-based diagnostics fall short in real care settings because the settings are not controlled: ambulances lose connectivity, rural clinics lack reliable bandwidth and home-care networks are inconsistent. For arrhythmia detection, latency is a clinical risk, not a performance metric, because a medical device flagging atrial fibrillation seconds late may miss the window for intervention. Detection must happen on the device.
Many cardiac monitoring solutions rely on cloud infrastructure for analysis. In controlled environments, that works. In real life, it often doesn’t.
Ambulances lose connectivity. Rural clinics don’t have reliable bandwidth. Home-care environments depend on inconsistent networks. For arrhythmia detection, latency is not just a performance metric; it’s a clinical risk.
A system that detects atrial fibrillation or ventricular abnormalities seconds too late may miss the window for intervention. That reality made the architectural decision straightforward:
All detections had to happen on the device.
No cloud inference. No round-trip delays. No dependency on external infrastructure.
One of those three settings has a standard that describes it. IEC 60601-1-11 defines the home healthcare environment as “the dwelling place in which a patient lives; other places where patients are present both indoors and outdoors, excluding professional healthcare facility environments where operators with medical training are continually available when patients are present”. A medical device designed for that definition has nobody trained beside it and no guaranteed network, which is the whole case for detection on the device.
What constraints does on-device arrhythmia detection face?
On-device arrhythmia detection faces four constraints at once: a small microcontroller such as a Cortex-M4, tightly limited RAM and flash, a power budget set by continuous operation on a battery and a real-time ECG sampling requirement that never pauses. With no GPU and no neural accelerator, the medical device has to spend every byte, millisecond and microamp deliberately.
From the outset, medical device hardware design defined the boundaries.
The worked example worked with:
- A Cortex-M4 MCU
- Extremely limited RAM and flash
- Strict power budgets for continuous operation
- Real-time ECG sampling requirements
There was no GPU. No neural accelerator. No margin for inefficiency. Every byte mattered. Every millisecond mattered. Every microamp mattered.
This was not a problem that could be solved by “making the model smaller” alone. It required rethinking the entire system from signal acquisition to firmware scheduling to inference execution.
The constraints of the worked example, why each matters clinically and where it is handled
| Constraint in the worked example | Why it matters clinically | Where it is handled |
|---|---|---|
| A Cortex-M4 class microcontroller | No GPU or accelerator; inference must fit the core | Model design and fixed-point inference |
| Limited RAM and flash | The whole pipeline must fit or it does not ship | Quantisation, layer removal, feature extraction |
| Strict power budget | A flat battery is a missed arrhythmia | Firmware sleep modes, DMA, scheduling |
| Continuous real-time ECG sampling | A dropped or drifting sample is a missed beat | Timer configuration, event-driven firmware |
The processor in the worked example is a part class a buyer can specify today. Arm describes the Cortex-M4 as “a high-performance embedded processor developed to address digital signal control markets that demand an efficient, easy-to-use blend of control and signal processing capabilities”, which is a vendor’s description of its own product, not a clinical claim. The point for a buyer is the class: a control-and-signal microcontroller, not an application processor, is what the budget for a continuously worn medical device usually allows.
How do you rethink the embedded stack for TinyML?
You rethink the embedded stack for TinyML by reversing the usual order: instead of starting with a model and forcing it onto the medical device, the system is designed backwards from the constraints across three coupled layers, hardware-aware signal acquisition, power-efficient firmware architecture and compact, deterministic inference. It means one team owns the sensor, the firmware timing and the model.
Rather than starting with an ML model and forcing it onto embedded hardware, the process was reversed: the system was designed backward from the constraints.
That meant rebuilding the stack across three tightly coupled layers:
- Hardware-aware signal acquisition
- Power-efficient firmware architecture
- Ultra-compact, deterministic ML inference
This is where hardware firmware development becomes a systems discipline, not just an implementation task.
The layer boundaries are set by the part: a Cortex-M4 class core has no accelerator to hide an inefficient model behind, so the acquisition and firmware layers have to do work the model cannot.
How do you make TinyML clinically viable?
You make TinyML clinically viable by cutting computational cost without cutting clinical signal integrity: quantising weights, removing redundant layers and operations, simplifying feature extraction and designing inference for fixed-point arithmetic, then checking that detection accuracy holds. In the worked example the whole inference pipeline fits a footprint of roughly 120 KB with deterministic, predictable latency on the medical device.
The original arrhythmia detection model performed well on larger systems but was unsuitable for embedded deployment.
Instead of blindly compromising accuracy, the work focused on preserving clinical signal integrity while aggressively reducing computational cost.
Key steps included:
- Quantising the model to sub-8-bit weights without degrading the F1 score
- Eliminating redundant layers and operations
- Optimising feature extraction to reduce runtime complexity
- Designing inference paths for fixed-point arithmetic
The result:
- The full inference pipeline fits within a ~120KB footprint.
- Deterministic execution with predictable latency
- Clinically meaningful detection accuracy preserved
This was not about shrinking AI for novelty. It was about making intelligence accountable at the point of care.
A model that runs inside a medical device is part of that device’s software, and IEC 62304 defines the life cycle requirements for medical device software. The practical consequence for a buyer is that the quantised model and its version belong in the same software life cycle as the rest of the firmware, so the question to ask a supplier is where the model version and the evidence behind its detection accuracy are recorded, and who can reproduce that accuracy figure from what is recorded.
Why is signal processing as critical as the model?
Signal processing is as critical as the model because raw ECG is messy: motion artefacts, electrode impedance changes and environmental noise can overwhelm a naïve model on a constrained medical device. A real-time preprocessing pipeline that filters baseline wander and high-frequency noise, normalises the signal and segments PQRST complexes before inference lets the model see physiology rather than noise.
In cardiac diagnostics, raw ECG data is messy. Motion artefacts, electrode impedance changes, and environmental noise can easily overwhelm naïve ML models, especially on constrained devices.
A real-time ECG preprocessing pipeline was built that:
- Filtered baseline wander and high-frequency noise
- Normalised signals dynamically
- Segmented PQRST complexes accurately at 200Hz
All preprocessing ran locally, before inference.
This approach ensured that the TinyML model focused on physiologically relevant features instead of compensating for noise. In embedded medical systems, good signal conditioning often matters more than model depth.
Why is firmware the backbone of an on-device detection system?
Firmware is the backbone of an on-device detection system because it orchestrates, under strict timing and energy limits, everything the medical device does: continuous ECG sampling, real-time preprocessing, inference, alert generation and power management. Event-driven tasks instead of polling, DMA transfers, aggressive sleep between acquisition windows and drift-free sampling timers are what turn a model into a device that runs.
None of this would have worked without disciplined firmware development services.
The firmware was responsible for orchestrating:
- Continuous ECG sampling
- Real-time preprocessing
- ML inference execution
- Alert generation
- Power management
All under strict timing and energy constraints.
Key firmware optimisations included:
- Event-driven task execution instead of polling loops
- DMA-based data transfers to minimise CPU load
- Aggressive use of sleep and stop modes between acquisition windows
- Precise timer configuration to maintain 200Hz sampling without drift
The result was a system that delivered:
- <50ms inference latency
- <5mA average current draw
- Continuous operation without thermal or stability issues
Firmware wasn’t just glue code; it was the control layer that made the system safe, responsive, and reliable.
The firmware techniques the worked example uses, what each saves and what it protects
| Firmware technique | What it saves | What it protects |
|---|---|---|
| Event-driven tasks, not polling | Processor wake-ups and idle current | The power budget |
| DMA-based data transfers | Processor time during sampling | Inference latency headroom |
| Sleep and stop modes between windows | Average current between acquisitions | Battery life, thermal margin |
| Precise sampling timer | Timing drift across long runs | The ECG record itself |
Each technique is a decision taken in the firmware architecture, not a tuning pass at the end, which is why a power budget that looks wrong late in a project is usually an architecture problem rather than a firmware bug. What firmware architecture work of this kind looks like as an engagement is set out on our page on firmware development for regulated and connected devices.
Why is power efficiency a safety requirement in medical wearables?
Power efficiency is a safety requirement in medical wearables because a drained battery means missed arrhythmias, lost diagnostic continuity and a patient who stops trusting the device. Treating power as a first-class safety constraint, rather than an optimisation goal, means aligning hardware capability, firmware scheduling and inference windows so the medical device runs continuously without giving up detection fidelity.
In medical wearables, battery life is not a convenience feature. It is a clinical requirement.
A drained battery means:
- Missed arrhythmias
- Loss of diagnostic continuity
- Compromised patient trust
Power was treated as a first-class safety constraint rather than an optimisation goal. With hardware capabilities aligned with firmware scheduling and ML execution windows, the device could run continuously for extended periods without sacrificing detection fidelity.
This balance is only achievable when medical device hardware design and firmware are developed as a single system.
Where a wearable of this kind runs on a rechargeable lithium cell, that cell carries its own standard, IEC 62133-2, for the safety of portable sealed secondary lithium cells and batteries, so the battery is a compliance item as well as a runtime one. How power is designed into a medical device from the architecture, rather than patched in firmware afterwards, is the subject of our post on how power optimisation changes MedTech devices.
How does on-device detection change clinical outcomes?
On-device detection changes clinical outcomes because the finished medical device can detect arrhythmic patterns in real time, analyse PQRST morphology locally and trigger an alert immediately, with no cloud access. Care does not happen in data centres; it happens in an ambulance, a village clinic or a home, where there is time only to detect, decide and intervene.
The finished system could:
- Detect arrhythmic patterns in real time
- Analyse PQRST morphology locally
- Trigger alerts immediately without cloud access
This matters because care doesn’t happen in data centres. It happens to patients.
In an ambulance, a village clinic, or a home-care setup, there is no time to sync, upload, or wait. You only have time to detect, decide, and intervene.
Detecting and alerting is the function this kind of device exists for, and IEC 60601-1 contains requirements concerning basic safety and essential performance that are generally applicable to medical electrical equipment. A buyer can ask a supplier whether that function is written down as essential performance for the device, and what the device does when it cannot perform it.
Is on-device detection an edge versus cloud choice, or responsibility placement?
On-device arrhythmia detection is not an edge versus cloud choice; it is responsibility placement. The question is where intelligence must live to protect the patient, and for arrhythmia detection the answer is on the medical device: first-line detection must be immediate, deterministic and independent of any connection. Cloud analytics keep long-term monitoring and population insight, not the first line.
This worked example reinforced an important lesson:
The debate is not “edge vs cloud.”
The real question is: Where must intelligence live to protect the patient?
For arrhythmia detection, the answer is clear: on the device.
Cloud analytics still play a role in long-term monitoring and population insights. But first-line detection must be immediate, deterministic, and independent. Embedded intelligence makes that possible.
The placement question is sharpest in the setting IEC 60601-1-11 calls the home healthcare environment, where no operator with medical training is continually available. The same placement question runs through every connected medical device, not only cardiac ones; the wider picture, from real-time processing to edge computing and security, is the subject of our post on how embedded systems are revolutionising healthcare.
Why does scaling MedTech require embedded accountability?
Scaling MedTech requires embedded accountability because when AI runs in the cloud responsibility is abstracted, and when it runs on the medical device responsibility is embedded in it. Every inference then has to be predictable, explainable, power-aware and safe under failure. The buyer’s question is where each of those properties is evidenced before the device ships.
When AI runs in the cloud, responsibility is abstracted. When AI runs on-device, responsibility is embedded.
Every inference must be:
- Predictable
- Explainable
- Power-aware
- Safe under failure
This fusion of edge engineering and clinical responsibility enables MedTech solutions to scale beyond controlled environments.
It’s not just about low-power AI. It’s about trustworthy intelligence, placed where it matters most.
Predictability, explainability and safe behaviour under failure have to be evidenced somewhere, and for software inside a medical device that evidence belongs in the design records a buyer will ask to see. IEC 62304 defines the life cycle requirements for medical device software.
What does on-device arrhythmia detection demand of a medical engineering team?
Building an on-device arrhythmia detection system teaches that medical engineering is defined by tight constraints, zero tolerance for failure and the need for absolute reliability, and that the model is the smallest part. The medical device around it, its signal conditioning, its firmware and its power design, is what makes the intelligence accountable at the point of care.
Building an on-device arrhythmia detection system meant confronting the realities of medical engineering’s tight constraints, zero tolerance for failure, and the need for absolute reliability.
At Pinetics, this is the mindset we bring to every engagement. With deep expertise in medical device hardware design, firmware development services and hardware firmware development, we help MedTech innovators build systems that deliver real clinical value under real-world conditions: the sampling and alert latencies written down before a model is chosen, the firmware architecture that decides the power budget, the battery treated as a safety item and the model versioned and validated as medical device software. That work rests on 100,000+ engineering hours and a leadership team with 20+ years of experience, and it runs inside the customer’s quality system rather than under a certification of our own. If your device must detect and decide with no connection and nobody trained beside it, the conversation starts with which detections must happen on the device, the latency an alert may tolerate, the battery life the use demands and how the model will be validated as software.
When intelligence becomes ambient, embedded, and accountable, MedTech doesn’t just innovate; it becomes accountable. It saves lives.
Alankar Dhobale, Co-Founder and Global CTO, Pinetics. 21+ years in electronic product development. BE Electronics, Shivaji University. LinkedIn
