ECHOTRIAGE

• 

• 

• 

Inspiration

In a disaster or mass-casualty situation, the problem is not always a lack of medical knowledge — it is a lack of time, clinicians, and continuous attention.

When dozens or hundreds of patients need care simultaneously, healthcare workers cannot continuously monitor every patient. A patient who initially appears stable may deteriorate later, while another patient may require less urgent attention.

This led me to a simple question:

What if a device could continuously watch over patients and tell clinicians who needs attention first?

What it does

I am building a low-cost, attachable patient-monitoring device designed for disaster and resource-limited settings.

Instead of trying to replace a doctor or make a diagnosis, the goal is to provide continuous monitoring and early warning.

The device is designed to collect physiological signals such as respiratory and cardiac sounds, along with other basic parameters, and establish a patient's baseline. It can then look for significant deviations from that individual's normal pattern and flag patients who may need reassessment.

The broader vision is a system where a clinician does not have to constantly check every patient manually.

Instead:

Patient → Continuous monitoring → Baseline/deviation detection → Alert → Clinician prioritization

This could allow limited medical personnel to spend more time on patients who actually require attention.

How I built it

I started with a small hardware prototype using an ESP32 as the processing and communication platform.

For respiratory and cardiac sound acquisition, I experimented with an INMP441 I2S MEMS microphone. I also planned integration of additional sensors, including an MPU6050, to capture complementary physiological information.

The initial prototype was deliberately simple. I wanted to first answer a fundamental question:

Can inexpensive hardware reliably, capture clinically meaningful physiological signals?

I wrote firmware using the Arduino environment to acquire audio through I2S and experimented with sampling rates, microphone configuration, signal amplitude and noise.

I then built a Python-based pipeline to record and analyse the signals. I compared characteristics such as:

RMS amplitude, Standard deviation, Signal amplitude/range, Time-domain waveform characteristics Spectral and Mel-spectrogram representations

For respiratory sounds, I also worked with a dataset containing thousands of respiratory cycles and experimented with machine-learning approaches for distinguishing abnormal from normal breath sounds.

The eventual goal is to move beyond simply classifying a sound as "normal" or "abnormal" and instead develop a patient-specific baseline and deviation-based alert system.

Challenges I ran into

The biggest challenges so far have been :

Reliable signal acquisition - obtaining clean physiological signals from inexpensive hardware. Environmental noise - disaster environments are very different from controlled clinical recordings. Limited datasets - publicly available respiratory sound datasets do not perfectly represent real disaster settings. Generalization - a model trained on one dataset may not perform similarly on different devices, patients or environments. Choosing the right objective - detecting every abnormal sound is not necessarily the same as identifying the patient who needs urgent attention.

That last point changed how I think about the project.

The ultimate goal is not:

"Can my model diagnose this patient's lung disease?"

It is :

"Can my system help a clinician notice that this patient is deviating from their baseline and may need attention?"

Accomplishments that I'm proud of

Why It Matters

In a well-staffed hospital, continuous monitoring can already be performed using sophisticated equipment.

The challenge is what happens when there are too many patients and too few clinicians.

That is where I see the potential value of a low-cost, scalable monitoring system.

This project is still at an early prototype stage, and there is a long way to go before it could be used clinically. The current prototype is primarily a proof of concept for the hardware, signal-acquisition and data-analysis pipeline.

But the direction is clear:

Build something inexpensive enough to deploy widely, simple enough to attach to a patient, and intelligent enough to help scarce healthcare workers decide who needs attention first.

What I learnt

Building this project taught me that developing a medical AI system is not just about training a model. Reliable signal acquisition, noise, hardware limitations, patient-to-patient variability, and data quality can matter just as much as the algorithm itself.

I also learned the importance of patient-wise data splitting to avoid misleading model performance, and that the real-world goal should be defined carefully: rather than simply detecting abnormalities, the system should help identify meaningful deviations from a patient's baseline that may require clinical attention.

What's next for ECHOTRIAGE

The next stages are to improve the hardware reliability, integrate additional physiological sensors, collect better patient-level data, and develop a robust baseline/deviation detection pipeline.

Ultimately, I want to build a system that functions less like a conventional diagnostic device and more like a continuous safety net for patients when medical resources are stretched beyond capacity.

Built With

• arduino
• biomedical
• cnn
• digital
• engineering
• esp32
• forest
• healthcare
• i2s
• inmp441
• learning
• machine
• medical
• mpu6050
• processing
• python
• random
• signal
• tensorflow