Show HN: Aidlab – Health Data for Devs
19 comments
> Now we're doing everything we can to move computation to the edge. In an ideal world, the cloud wouldn't store or process anything - just receive already-analyzed, privacy-preserving results straight from the device.
I appreciate moving away from cloud for personal health data like this.
Can you clarify why the ideal world you hint at would have the device sending any data to you?
I appreciate moving away from cloud for personal health data like this.
Can you clarify why the ideal world you hint at would have the device sending any data to you?
Devices sending data that is anonymized, encrypted, and signed by the device is a must-have for some medical studies.
For example, imagine a medical study that looks at heart rate variability versus an intervention. The data analysts won't need to know each patient's name or email address, but will need to know each patient's heart rate variability when you're having the intervention. The study may span many physical locations, such as at multiple medical providers across a country.
For example, imagine a medical study that looks at heart rate variability versus an intervention. The data analysts won't need to know each patient's name or email address, but will need to know each patient's heart rate variability when you're having the intervention. The study may span many physical locations, such as at multiple medical providers across a country.
Ditto on this! I've avoided fitness trackers so far because I don't want any cloud aka my data on someone else's computer
for regular users, since the device itself doesn't have any interface, we need to send at least some data so they can see it somewhere. the natural place is the phone, but not all of our professional clients liked viewing long ECG recordings or detailed metrics on a small screen, so we built cloud access mostly for convenience .
(to be clear - if a developer wants, they don't need to send anything to us)
(to be clear - if a developer wants, they don't need to send anything to us)
I watch "Quantified Scientist" (https://www.robterhorst.com/), in which Rob compares various watches and smartbands on how they measure sleep and heart rate - against golden standards.
By any chance, were you able to talk with him so he can measure it?
By any chance, were you able to talk with him so he can measure it?
Hey there,
We haven’t spoken with Rob yet but that is a great suggestion. Thanks for the tip!
We haven’t spoken with Rob yet but that is a great suggestion. Thanks for the tip!
I thoroughly applaud your approach.
I've been dealing with some cardiac issues that were brought on / exasperated by a covid infection, and it's been challenging finding solutions that let me monitor my own biometrics while hiking without sending anything to the cloud. It's shocking that it's a non-trivial endeavor to pair a medical grade wearable with a smartphone and get differentiated granular alarms / alerts for user defined events (BPM within user defined bands, blood oxygen levels below a certain threshhold, etc..)
If your python SDKs work wirelessly, I'd seriously consider creating a RPI based system to do those things and be able to leave the smartphone at home while I hike.
I've been dealing with some cardiac issues that were brought on / exasperated by a covid infection, and it's been challenging finding solutions that let me monitor my own biometrics while hiking without sending anything to the cloud. It's shocking that it's a non-trivial endeavor to pair a medical grade wearable with a smartphone and get differentiated granular alarms / alerts for user defined events (BPM within user defined bands, blood oxygen levels below a certain threshhold, etc..)
If your python SDKs work wirelessly, I'd seriously consider creating a RPI based system to do those things and be able to leave the smartphone at home while I hike.
Hey, can you join our Discord: https://discord.gg/sPay3Xm? Reach out to me personally (@guzik1) - happy to help you with that as we've already had a few people who integrated with rpi, so I can share some tips and examples.
When you're ready with Aidlab 2, can you contact me? I work for a national health service and I'm keen to learn more, buy, and generate some public anonymized data sets. [email protected]. Thanks and good work! <3
Any information on how comfortable the strap is? I am wearing a Garmin HRM Pro for one hour a day during workouts and it is not very comfy. I know a lot of athletes are moving to way less precise optical hand straps just because of the comfort issues with chest straps. I would not wear a chest strap for longer periods of time, unless I absolutely had to.
sadly, comfort for chest straps compared to hand straps is a known issue and ours is definitely no different. Wve done a bunch of tests, tried different materials/custom solutions, and honestly we're still clueless how to make it significantly better (if anyone here works in textiles or wearable fabrics, I'd love to connect). So yeah, if wearing your Garmin for more than an hour already feels uncomfortable, ours probably won't be much better in that regard
Nice idea. Wonder if you can use web Bluetooth to connect a web page directly to it?
Having glucose would be cool too.
Having glucose would be cool too.
Thanks! Yep, the interface for a shell is available here: aidlab.com/developer/debug we are using Jquery Terminal + Web Bluetooth (sadly, I think it's not under active development anymore)
and yeah, when we started years ago, it felt natural that the next step would be to measure glucose from blood but the truth is with the current state of science, it's still not possible to do that 100% non-invasively.
and yeah, when we started years ago, it felt natural that the next step would be to measure glucose from blood but the truth is with the current state of science, it's still not possible to do that 100% non-invasively.
Plans for blood glucose?
Unlike health trackers with locked-down APIs, Aidlab ships with a free SDK [1] across 6+ platforms so you can just pip install aidlabsdk or flutter pub add aidlab_sdk or whatever platform (even Unity), and start streaming raw health data and events in real time with simple didReceive*(timestamp, value) callbacks.
Currently, we are exposing 13 data types including raw ECG, cough/snoring, motion, raw respiration, skin temperature, bodyweight reps, body position, and 20 high-level stats like stress or readiness through the API.
The most common questions I got are:
1) "how is it better than my smartwatch?"
2) "why we built it?"
Chest-mounted wearables are considered the gold standard for physiological measurements. For example, whenever Apple validates their watch, they benchmark against chest straps [2], as some signals can only be reliably measured (or measured at all!) near the heart including continuous ECG, true respiration (based on lung volume changes) or body position/orientation.
As for the second question: the problem for us was that smartwatches were too simple and the data too inaccurate, while advanced medical devices were too pricey or too complicated. We found a sweet spot between accuracy and accessibility - Aidlab delivers medical-grade signals without the hospital-level complexity. As "medical-grade" is a bold statement, we’ve published validation papers comparing Aidlab’s performance with other certified medical devices [3].
Today Aidlab is already a pretty mature concept. We've been building Aidlab for 2 years, shipped our first version in 2020, we got our first clients including Boeing/Jeppesen (monitoring pilots’ bio-signals during tests&training).
Now we're about to release Aidlab 2 [4] - with additional signals like EDA and GPS, and a bunch of new features, including on-device ML (we've trained a few small LSTM models running inference with TensorFlow Lite for Micro). The cool part is that we've built a custom shell on top of FreeRTOS, letting anyone invoke POSIX-like commands directly on the device, for example:
timeout 10 temperature --sampling-rate 1 | tee /data/temperature.csv | tail -n 5
The biggest breakthrough for us was realizing that cloud-based processing was the wrong approach. In the beginning, we pushed most of the computation to the cloud - it seemed natural, but turned out to be slow, costly, and devs didn't want it ("hey, is there a way to use your product without cloud?"). For example, our ECG analysis pipeline used to send raw data to an external microservice, processing it in 30-minute chunks through Bull queues. A 24-hour Holter analysis could spawn 100k+ event objects and take significant time to complete. Now we're doing everything we can to move computation to the edge. In an ideal world, the cloud wouldn't store or process anything - just receive already-analyzed, privacy-preserving results straight from the device.
Another lesson: don't hand-solder prototypes at 3 a.m. to save money -> please pay professionals to assemble PCBs.
We decided to showcase this now for three reasons:
- health feels more relevant than ever with the rise of longevity research and biohacking,
- we are close to finalizing Aidlab 2,
- and I am super curious to see if anyone here finds it useful!
If you'd like to check the quality of Aidlab for yourself, we are publishing free datasets every week during different activities [5].
[1] https://github.com/Aidlab
[2] https://www.apple.com/health/pdf/Heart_Rate_Calorimetry_Acti...
[3] https://aidlab.com/validation
[4] https://aidlab.com/aidlab-2
[5] https://aidlab.com/datasets