Research Paper: Real-Time Epilepsy Detection with IMU and Low Power Processor Design

[44616E]

G'day,
I came across this paper recently and seems to have a novel method for filtering which achieves very low false positives and good accuracy. While its using an IMU it appears to primarily only use accelerometer data.

https://ieeexplore.ieee.org/document/10012112

[jones139]

Thanks for sharing this - I had not seen this paper before.
It is interesting because I think the approach is not that far off what we are using for OpenSeizureDetector - they are using a 2.5-7.0 Hz region of interest, whereas we use 3 - 8 Hz.
One big difference seems to be an assumption that there is a period of very little movement before the seizure - if we were to make that assumption it would get rid of a lot of the false alarms we see in OpenSeizureDetector from things like cooking and typing, where it is unlikley to have a period of very little motion before the activity. My concern would of course be how valid that assumption is.
We have a system set up to use the data collected using the OpenSeizureDetector Data Sharing system to allow us to test different algorithms - I might try adding a requirement to have very little movement for, say 15 seconds before we activate an alarm and see what that does to our accuracy and false alarm statistics - thanks!
Graham
@jpordoy - you might be interested in this one too?

[jones139]

....but my statement above is based on a very quick scan through the paper, so please correct me if I missed something - the OpenSeizureDetector algorithm is described here: https://www.openseizuredetector.org.uk/?page_id=455

@jpordoy is currently working on a couple of papers for hist PhD which describe the OpenSeizureDatabase and some neural network based algorithms he has developed - if you are interested it might be worth the three of us having a talk about them if we can find a suitable time for us all?

[jones139]

I have had another read through the paper, and do think it is worth looking at. For some reason they did not use Fourier Transforms to switch into the frequency domain like we do - maybe they could not implement it on the chip they were targeting, so instead they are counting peaks etc. So the biggest difference to our current algorithm is adding an expectation of some very low movement time before the seizure movements develop. This will definitely reduce our false alarm rate, because when things like typing generates alarms, it is a fairly continuous movement.
My concern is that at the moment the OSD algorithm detects quite a lot of other seizures, in particular partial ones, and the assumption that we have a period of no movement might not be valid for these seizures. So I think what I will do is:

1. Set up a test algorithm in python to implement the requirement for no movement in the period for it to generate an alarm.
2. Compare what this does to the detection reliability for tonic-clonic seizures and other seizures - what I would expect if the assertion in the paper is correct is that we would get about the same detection reliability for tonic-clonic seizures, but the reliability for other seizures will fall.
3. Compare the false alarm performance on our database of false alarms and normal daily activities - we would expect to see a significant reduction in the number of false alarms.

If that is the case, it is then a decision for the users about what they would rather see - reduced false alarm rate at the expense of detecting non-tonic-clonic seizures, or keep the false alarm rate and high seizure detection reliability.
It will probably vary by users - for us where we use the system on a night, the false alarm rate is acceptable. For people trying to use it while going about more normal daily activities, they might prefer to have the reduced false alarm rate and only be able to detect tonic-clonic seizures reliably - so have a user selected mode of operation? This might be roughly equivalent to the 'rest mode' that the Empatica Embrace has where the sensitivity is increased if you know the wearer is not doing too much vigorous activity.

Will let you know when I have the test version set up and have some results.
Thanks!
Graham.

[44616E]

Hi Graham,It is interesting, we are primarily using it at night as well. As soon as he wakes up and plays the alarm goes off.I am also suspect of the acc in the garmin watch, just from what I have read and the data I have seen I'm not convinced it has a correct antialias filter which may impact fft as high freq may contaminate the data. Curious on your thoughts and observations.This paper I found also suggests something is uphttps://www.medrxiv.org/content/10.1101/2023.05.25.23290556v1.fullI was going to get a shaker table at work, shame that didn't happen would have been interesting to do some extra tests.I like the look of a PineTime. There doesn't seem to be any dev kits available. I wouldn't mind have a crack at it. What path were you thinking of, did you plan to have an app to install on the watch or a dedicated firmware to make it a dedicated device. I would probablely be interested in the latter.I am concerned a little over long term hardware availability considering the delays in OS development.In relation to the hr update issue it didn't occur on the ben version but could be a coincidence. Shall keep monitoring. Spo2 has stopped updating on the watch the value shown in the OSD app is more than 24 hours old currently. Not sure why it doesnt show null instead. Not sure if its a positional issue or something else it is enabled for all day measurements. My sons wrists are too small to fit the watch so its on his bicep.This project shows how to read the wellue rings seems relatively easy surprisingly.https://github.com/ecostech/viatom-bleThe IMU idea I head was to start with something like this https://www.seeedstudio.com/Seeed-XIAO-BLE-Sense-nRF52840-p-5253.html$16 with 6dof imu, ble and battery charger. Just need a case (3d printed) and battery. It also has a machine learning core (haven't looked into that much yet). Combine this with a welue ring seems like an interesting option.The wellue devices we have tried so farKids ringhttps://getwellue.com/pages/kidso2-child-oxygen-monitorWas good, alittle small got knocked off a few times. Was lost on the way to the emergency department. But did end up finding it a month later, so its now a spare. There is an adult version.Checkme O2https://getwellue.com/products/checkme-o2-max-wrist-pulse-oximeterVery long battery life (70 hours of recording), and doesn't fall off. Solid hr and O2 readings all night. Both also have an accelerometer but the data is just magnitude and unitless and 1Hz.ThanksDan. -------- Original message --------From: Graham Jones ***@***.***> Date: 23/7/23 7:30 pm (GMT+08:00) To: OpenSeizureDetector/Android_Pebble_SD ***@***.***> Cc: 44616E ***@***.***>, Author ***@***.***> Subject: Re: [OpenSeizureDetector/Android_Pebble_SD] Research Paper: Real-Time Epilepsy Detection with IMU and Low Power Processor Design (Discussion #115) I have had another read through the paper, and do think it is worth looking at. For some reason they did not use Fourier Transforms to switch into the frequency domain like we do - maybe they could not implement it on the chip they were targeting, so instead they are counting peaks etc. So the biggest difference to our current algorithm is adding an expectation of some very low movement time before the seizure movements develop. This will definitely reduce our false alarm rate, because when things like typing generates alarms, it is a fairly continuous movement. My concern is that at the moment the OSD algorithm detects quite a lot of other seizures, in particular partial ones, and the assumption that we have a period of no movement might not be valid for these seizures. So I think what I will do is: Set up a test algorithm in python to implement the requirement for no movement in the period for it to generate an alarm. Compare what this does to the detection reliability for tonic-clonic seizures and other seizures - what I would expect if the assertion in the paper is correct is that we would get about the same detection reliability for tonic-clonic seizures, but the reliability for other seizures will fall. Compare the false alarm performance on our database of false alarms and normal daily activities - we would expect to see a significant reduction in the number of false alarms. If that is the case, it is then a decision for the users about what they would rather see - reduced false alarm rate at the expense of detecting non-tonic-clonic seizures, or keep the false alarm rate and high seizure detection reliability. It will probably vary by users - for us where we use the system on a night, the false alarm rate is acceptable. For people trying to use it while going about more normal daily activities, they might prefer to have the reduced false alarm rate and only be able to detect tonic-clonic seizures reliably - so have a user selected mode of operation? This might be roughly equivalent to the 'rest mode' that the Empatica Embrace has where the sensitivity is increased if you know the wearer is not doing too much vigorous activity. Will let you know when I have the test version set up and have some results. Thanks! Graham. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[jones139]

I have split my reply to different discussions to keep the different topics separate, so please see #70 about the PineTime support.

I am less concerned about aliasing than you I think - this was always a concern at the start - sampling at 25Hz means we can only detect up to 12.5 Hz without aliasing. When we first started, I did try to see if I could see any aliasing by wearing the watch and shaking progressively faster, while monitoring the simple spectrum graph on the phone app. If we do have an aliasing problem you would expect to be able to make the peak in the graph move to the right, but then rather than disappearing off the right hand side of the graph as you move faster, it would reappear at just over 6 Hz (12.5 Hz / 2). I have not been able to see this - I struggle to get my arm movement up to 10 Hz, so I am fairly confident that repetitive human movement will not be more than 12.5 Hz. [We will get a spike at over 12.5Hz in for instance a fall, but this is a one-off event, and we effectively average the spectrum over a 5 second period, and need at least 2 successive 5 second periods to have an excess of power in the 3-8 Hz range to generate a warning].

I do like the idea of a shaker table though - I keep meaning to make something simple to use for testing of physical devices - a motor with a cam to give us 1D movement - just need to make sure it could go fast enough without shaking itself apart, otherwise might need a speaker coil or possibly a solenoid that we could pulse?

@44616E Are you signed up to the data sharing system? If so, let me know the ID of one of your early morning false alarms and I'll run my analysis through the event to see if I can see what is happening.

I'll reply on the point on the Garmin Heart Rate here OpenSeizureDetector/Garmin_SD#22

[jones139]

@44616E, there is one other issue that could give rise to aliasing - we are working on vector magnitude and not the individual acceleration values - this is a bit like running AC through a rectifier, so the fft will actually be more complicated than it would be for a simple sine wave etc. But again, I did not see this from my testing - it was the main reason I was interested in making a shaker table for the watch though.

[44616E]

I think your probably right with human moverment not being much above 25Hz. But toys and impacts will be higher. For instance playing with toy cars and other toys where impacts are involved. It something I plan to investigate once I get the external O2 sensors working through the app.

[jones139]

I have had a look at a typical short tonic-clonic seizure from the database (see analysis in pdf file below)
Event_77999.pdf

Unfortunately this does not have the period of very little movement before the seizure movements start that the paper above assumes, and relies on to get the good false alarm behaviour. I would not want OSD to fail to detect these seizures because there was too much movement at the start (because this one successfully woke us up at 1am this morning to warn us to check on Benjamin!).

Or do you think I am misinterpreting what the paper is saying about 'quiet' times before the seizure movement?

Regards, Graham

[44616E]

I will have another read, I need to spend some more time on it. I wonder if the Authors would be up for answering questions?

[robertcaswell]

I have had a look at a typical short tonic-clonic seizure from the database (see analysis in pdf file below) Event_77999.pdf

Unfortunately this does not have the period of very little movement before the seizure movements start that the paper above assumes, and relies on to get the good false alarm behaviour. I would not want OSD to fail to detect these seizures because there was too much movement at the start (because this one successfully woke us up at 1am this morning to warn us to check on Benjamin!).

Or do you think I am misinterpreting what the paper is saying about 'quiet' times before the seizure movement?

Regards, Graham

Hi Graham,
Can I please ask why your Alarm Threshold is set to 900 rather than the default of 100?

We have been getting a lot of false alarms from movement lately - I am wondering if this would reduce them?
Data Sharing working from today - perhaps will shed some light.
Thanks
Rob

[jones139]

Hi Rob, Yes, it is to stop it alarming if there is very little movement. You should not go much above that value though as it starts to reduce the detection reliability. If you get data sharing running I'll have a look at some of your false alarms for you. Graham

…

On Sat, 19 Aug 2023, 04:37 robertcaswell, ***@***.***> wrote: I have had a look at a typical short tonic-clonic seizure from the database (see analysis in pdf file below) Event_77999.pdf <https://github.com/OpenSeizureDetector/Android_Pebble_SD/files/12139807/Event_77999.pdf> Unfortunately this does not have the period of very little movement before the seizure movements start that the paper above assumes, and relies on to get the good false alarm behaviour. I would not want OSD to fail to detect these seizures because there was too much movement at the start (because this one successfully woke us up at 1am this morning to warn us to check on Benjamin!). Or do you think I am misinterpreting what the paper is saying about 'quiet' times before the seizure movement? Regards, Graham Hi Graham, Can I please ask why your Alarm Threshold is set to 900 rather than the default of 100? We have been getting a lot of false alarms from minimal movement lately - I am wondering if this would reduce them? Alas, I have yet to get Data Sharing working, will try again. Thanks Rob — Reply to this email directly, view it on GitHub <#115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLSY5FNDJOBD3FXYCRSO3XWAYHTANCNFSM6AAAAAA2TV32QU> . You are receiving this because you commented.Message ID: <OpenSeizureDetector/Android_Pebble_SD/repo-discussions/115/comments/6766274 @github.com>

[AroonPro]

This is also why I made issue #119. After having traced the whole program for why calculation to 10e3 was necessary to scaling. After changing one calculation nanoseconds to seconds, I see in the graphs values higher than 9e9. Somewhere it must be around the fft I hope. Regards Op za 19 aug. 2023 05:37 schreef robertcaswell ***@***.***>:

…

I have had a look at a typical short tonic-clonic seizure from the database (see analysis in pdf file below) Event_77999.pdf <https://github.com/OpenSeizureDetector/Android_Pebble_SD/files/12139807/Event_77999.pdf> Unfortunately this does not have the period of very little movement before the seizure movements start that the paper above assumes, and relies on to get the good false alarm behaviour. I would not want OSD to fail to detect these seizures because there was too much movement at the start (because this one successfully woke us up at 1am this morning to warn us to check on Benjamin!). Or do you think I am misinterpreting what the paper is saying about 'quiet' times before the seizure movement? Regards, Graham Hi Graham, Can I please ask why your Alarm Threshold is set to 900 rather than the default of 100? We have been getting a lot of false alarms from minimal movement lately - I am wondering if this would reduce them? Alas, I have yet to get Data Sharing working, will try again. Thanks Rob — Reply to this email directly, view it on GitHub <#115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AV6J74YSEVBLT6CWI6KCY73XWAYHVANCNFSM6AAAAAA2TV32QU> . You are receiving this because you are subscribed to this thread.Message ID: <OpenSeizureDetector/Android_Pebble_SD/repo-discussions/115/comments/6766274 @github.com>