We developed a smartphone-based system for real-time fall detection and alert generation. The system’s performance was investigated in a prospective study for 23 individuals with varied diagnoses and conditions, leading to an elevated risk of falling. All the participants signed informed consent before study participation, which was approved by the Northwestern University institutional review board (NUIRB, IL, USA). All the study procedures were carried out in accordance with the standards listed in the Declaration of Helsinki 1964.
All consented participants in this study underwent screening for eligibility criteria. Participants who met the following criteria were enrolled: (1) Experienced at least one fall in the six months before the study; (2) Ability to follow instructions and give written consent. Exclusion criteria included: (1) Visual or cognitive deficits (Mini-Mental State Examination score < 17) that interfere with operating a smartphone; (2) individuals who are pregnant or planning to be pregnant.
During their enrollment visit, we collected the participant’s medical history as well as the scores of the modified falls efficacy scale (MFES) which measures the participant’s confidence in performing ADLs without falling  and the World Health Organization’s Quality of life brief version (WHOQoL-Bref) which measures the participant’s quality of life in four domains: physical health, psychological, social relationships, and environment .
Each participant was given a Samsung Galaxy S5 smartphone running on Android 6.0.1 with a pre-installed sensor data collection app, called Purple Robot, and the custom fall-detection module enabled [42, 43]. Purple Robot is an Android application developed for modular collection and processing of data streams available on a smartphone device. It allows for collection and processing of hardware data signals, as well as customizable notifications based on the processed signal outputs. A custom fall-detection module, implementing a model developed as part of prior work, was developed for use in this study. Nationwide unlimited talk/text data plan was enabled on these phones. Participants were provided with a brief functional overview of the Purple Robot app and its key features on the smartphone. Participants received a charger and a waist pouch if they chose to carry the phone around their waist. They were instructed to carry the smartphone during their awake hours for a continuous period of 90 days. No lifestyle alterations were suggested, and participants were advised to carry out their day-to-day activities as usual. All participants were residents of the Greater Chicago Area, which includes the city and its suburbs, yet they were free to travel with the smartphone within the borders of the United States.
During the 90-day trial, on every occasion when the system detected a fall, it generated a notification on the participant’s smartphone and sent a text message to a member of the research team. Participants or designated caregivers were contacted by a member of the research team in the same or next business day after receiving a fall notification to verify the fall and gather information on their wellbeing. During this follow up call, the research member would also collect a narrative description of the participants’ activity at the time of the alert, including what triggered the fall and how long the participants remained on the ground after the fall (if applicable). Further, the participants were instructed to call the research team in any case they experience a fall but were not contacted by the team during the next business day. Additionally, a member of the research team initiated periodic check-in calls every 20 days and asked for any falls that occurred and were not reported.
Status of the deployed phones (battery level, data plan usage) was monitored by the research team using the web portal. Participants were contacted by a research team member in case of no activity on the phone for three consecutive days.
At the end of the 90-day trial, the participants were invited to a final visit in which they returned the smartphone and were asked to provide feedback during a semi structured interview on the experience of using the fall detection app. During this visit, the participants were once more questioned regarding any fall event that was not detected during their study participation.
Fall detection model
We developed a hybrid model for the detection of real-life falls. The model includes a first-stage screening acceleration threshold and a second-stage machine learning classifier (see Fig. 1). The acceleration threshold screening reduces the computational burden by decreasing the number of events that had to be processed by the machine learning classifier.
This model was developed and validated using data from simulated falls and daily tasks performed in a laboratory setting by 17 participants . The participants included seven individuals with transfemoral amputation and ten healthy young adults with no elevated fall risk. While simulating the falls, participants carried a Samsung S5 smartphone that recorded accelerometer and gyroscope data from the built-in hardware sensors using the Purple Robot application. During the simulated falls recording, a researcher used a second phone to log and label the timestamps of the events.
The recordings were then split into 5-second data windows, similar to the window sizes in previous studies [45,46,47]. In order to provide many different examples of falls occurring in different portions of the 5-second windows (i.e., beginning, middle, end of the window), for each fall event we created ten windows, each a randomly-selected 5-second range including the fall-impact. The fall-impact was identified as the maximum acceleration magnitude occurring within 2.5 s of the fall-timestamp labeled during data collection. The smartphone application has a limited ability to sample the accelerometer and gyroscope signal at a consistent rate, due to resource demands from other applications on the device. To account for sampling rate inconsistencies, the accelerometer and gyroscope signals within each five-second window were interpolated to 250 samples at intervals of 20 ms, corresponding to 50 Hz frequency. To avoid generating signal artifacts through the interpolation process, we discarded windows including less than 200 samples or having a gap between consecutive samples larger than 200 ms. No filtering was applied to the data. This procedure resulted in a total of 8452 five-second data windows (7874 corresponding to falls and 578 corresponding to non-falls), which were used to train to the fall detection model.
The first stage of the fall detection model was the acceleration threshold screening. The threshold value was determined by assessing the maximum acceleration amplitudes of simulated falls versus non-falls. We found that all simulated fall events had peak acceleration magnitudes larger than 2 g, while 83.9 % of non-fall windows had peak acceleration below this value. Thus, we selected 2 g as the threshold value to ensure maximum sensitivity to falls while screening out the majority of non-falls events. High sensitivity is desirable for a first-step data screening, so as to not incorrectly remove true fall events before the final model stage.
The second stage of the fall detection model included a machine learning classifier. The classifier was trained only with data windows (both fall and non-falls) that included a peak acceleration above 2 g (i.e., passed the first-stage screening). For each of these data windows, a set of 40 features were computed (20 for the accelerometer and 20 for the gyroscope signals; Table 1). These features were used as inputs to a logistic regression model, which output a posterior probability (0–1) of a fall given the sensor data. In the final implementation on the mobile phone, this was binarized to a value of 0 for a non-fall activity and 1 for a fall after application of detection threshold, which was the 5th percentile of posterior fall probabilities across all simulated falls in the training set. To remove redundant features and avoid overfitting, a regularization procedure was applied using Elasticnet with parameters α = 0.6 and λ = 0.015 which were found through a cross-validation hyperparameter tuning . These hyperparameters were selected based on a parameter grid-search performed on leave-one-participant-out cross-validation folds. The hyperparameter tuning revealed consistent performance within each fold with respect to the grid-search range used. The hyperparameter values for the final model noted above were chosen because they representative of the center of the search space. The performance of this system was estimated using a leave-one-participant-out cross-validation, which resulted in an average area under the receiver operating characteristics (AUROC) of 0.995 (95-percent confidence interval (CI): 0.992–0.995). The decision threshold for the deployment model was set to 0.908, which is the fifth percentile fall probability among all simulated falls. This corresponds to an estimated sensitivity of 0.95 based on our simulated falls data. Applying the selected threshold resulted in the following average performance metrics: accuracy of 0.959 (CI 0.940–0.977), the sensitivity of 0.954 (CI 0.930–0.977), and specificity of 0.984 (CI 0.972–0.995). Training and analysis of the logistic regression model were performed in MATLAB 2017a. In this study we evaluated the model performance by measuring its precision (i.e., the fraction of true falls out of the detected falls), recall (the fraction of falls that were detected out of the falls that occurred), and F1-score (i.e., the harmonic mean of precision and recall).
Web portal and smartphone app
If the estimated fall probability value exceeded 0.908, the Purple Robot app generated two alerts: (1) A message appeared on the faller’s phone screen; (2) a text message sent to the phone of a member of the research team. In addition, the Google activity recognition application program interface (API) (30) was applied every 60 s to assess the type of activity being performed by the user in the preceding 60-s interval. To reduce the amount of data to be transmitted and to conserve battery life, records for the sensor signals, fall probabilities, and activity recognition data were only transmitted if they were included within 15 min of an estimated fall probability greater than 0.5. Regardless of the event fall probability, additional data recorded by the system included the Global Position System (GPS) coordinates and phone battery life, which was transmitted to the cloud server every 60 and 30 s, respectively. The Purple Robot application and custom fall detection model were programed in Java and compiled using Android Studio version 2.3.
In addition to the mobile application, a web portal was developed to allow the exploration of the collected data. The web portal enables the filtering of potential fall events by its probability. For each potential fall event (i.e., 5 s intervals with fall probability > 0.5) the portal presents the following details: (1) the fall date and time, based in the phone log; (2) the falling probability, based on the estimation of the fall-detection model; (3) the fall location, based on the GPS coordinates at the time of the fall; (4) the faller movement speed prior to the fall, based on average change in location over the five minutes before the fall; (5) the weather condition (i.e., sky conditions such as clear, cloudy, rainy) at the time and place of the fall, obtained from Weather Underground (https://www.wunderground.com), with the closest reported data point in both time and location and; (6) the faller’s activity at the time of the fall, based on the Google Activity Recognition API [49, 50], with the most likely activity and confidence level reported. The web portal includes additional fields of the type of fall (e.g., tripping forward, slipping backward), and fall confirmation, which was not implemented in the current study. The web portal was implemented using Django, which is an open-source Python framework for coding web services .