NilHRH commited on
Commit
2a41b2e
·
verified ·
1 Parent(s): fbb5ccc

Upload reports/limitations_and_safety.md with huggingface_hub

Browse files
Files changed (1) hide show
  1. reports/limitations_and_safety.md +31 -0
reports/limitations_and_safety.md ADDED
@@ -0,0 +1,31 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Limitations and Safety
2
+
3
+ ## Current Status
4
+
5
+ This project is a student prototype. The verified default pipeline uses synthetic IMU windows to test feature extraction, model training, model saving, evaluation, and demos.
6
+
7
+ ## Major Limitations
8
+
9
+ - Synthetic data does not represent the full variability of real Parkinson's symptoms, sensor placement, device drift, age, gait style, medication state, or home environments.
10
+ - The four labels are prototype event categories, not clinical diagnoses.
11
+ - The classifier is trained on short windows and does not understand patient history unless those features are added later.
12
+ - Public FoG datasets often cover normal versus FoG-like movement and may not include tremor or risky/unusual movement classes.
13
+ - Kaggle FoG data is accelerometer-only in common competition files, so gyroscope channels may be unavailable.
14
+ - High synthetic accuracy should be described only as pipeline verification.
15
+
16
+ ## Responsible Use
17
+
18
+ - Do not use this model to diagnose Parkinson's disease.
19
+ - Do not use this model to change medication, therapy, or cueing plans.
20
+ - Repeated concerning logs should be shared with a caregiver or qualified clinician.
21
+ - A risky/unusual movement alert should prompt a welfare check. Emergency action should depend on observed injury, fall, confusion, or unresponsiveness.
22
+ - The current alarm system is local-only. It records alarm events to a JSONL file and prints them in demos; it does not send SMS, email, push notifications, or emergency calls.
23
+ - The report-history chat answers from saved logs only. It should not be treated as a clinician, and it should not infer diagnoses from incomplete history.
24
+
25
+ ## Next Validation Steps
26
+
27
+ - Collect consented real wearable data with consistent sensor placement and clinical annotation.
28
+ - Validate across different users and recording sessions.
29
+ - Report sensitivity, specificity, false alert rate, and missed-event rate by event class.
30
+ - Test calibration and signal-quality rejection.
31
+ - Review all user-facing text with a clinician before real-world use.