Wearable Inertial Sensing for ICT Management of Fall Detection , Fall Prevention , and Assessment in Elderly

Falls are one of the most common causes of accidental injury: approximately, 37.3 million falls requiring medical intervention occur each year. Fall-related injuries may cause disabilities, and in some extreme cases, premature death among older adults, which has a significant impact on health and social care services. In recent years, information and communication technologies (ICT) have helped enhance the autonomy and quality of life of elderly people, and significantly reduced the costs associated with elderly care. We designed and developed an integrated fall detection and prevention ICT service for elderly people, which was based on two wearable smart sensors, called, respectively, WIMU fall detector and WIMU data-logger (Wearable Inertial Measurement Unit, WIMU); their goal was either to detect falls and promptly react in case of fall events, or to quantify fall risk instrumentally. The WIMU fall detector is intended to be worn at the waist level for use during activities of daily living; the WIMU logger is intended for the quantitative assessment of tested individuals during the execution of clinical tests. Both devices provide their service in conjunction with an Android mobile device. The ICT service was developed and tested within the European project I-DONT-FALL (Integrated prevention and Detection sOlutioNs Tailored to the population and risk factors associated with FALLs, funded by EU, action EU CIP-ICT-PSP-2011-5: GA #CIP-297225). Sensor description and preliminary testing results are provided in this paper.


Introduction
Falls represent a major public health problem requiring medical attention: among older adults (over 65), one in four falls annually, and one dies every 19 min as result of falling [1].Falling has significant consequences which affect the quality of life in the elderly, because falls can dramatically change an elderly person's self-confidence and motivation, thereby affecting their ability to live independently in a dramatically vicious cycle which tends to worsen with age.Even though human beings are all at risk of falling, some factors such as age, gender, health conditions, and the history of previous falls show remarkably high correlations to the type and severity of injuries which occur as a result of falling [2].Among healthy people, adults over 65 years of age experience high risk of serious injury due to falling, and this risk keeps increasing with age.In general terms, the risk of fall is related to extrinsic (environment-dependent) and to intrinsic factors (physical, sensory and cognitive changes typical of ageing); moreover, fear of falling is related to adopting overly-cautious gait habits [2], and this might in turn cause falls that result in increased risk of falls, fear of falling, and functional decline [3].As a result, fall prevention activities are carried out across a range of health disciplines including occupational therapy, physiotherapy, general practice, nursing, geriatric, gerontology health, and social care [4][5][6].Fall risk assessment concerns the evaluation of risk factors.
Relevant efforts in mitigating risk factors are targeted to physiological factors, which include muscle strength and balance, stability, posture, and gait reaction time [7].
Fall risk definition and instrumental assessment are relevant for adapting the level of assistance needed by elderly people and tailoring preventive measures to specific subjects that are deemed to be at high risk of falling.The risk of falling is generally evaluated using questionnaires, despite their associated problems of subjectivity and limited accuracy [8].A number of experimental tests (e.g., Berg balance scale, Timed Up and Go, Turn 180 • test) have been developed to screen older people in the community or in a clinical setting [7]; risk can also be evaluated by clinical and functional assessment including posture and gait, independence in daily life, cognition, and vision [8,9].However, previous studies still report limitations in accuracy and versatility, preventing routinely use of this process in clinical practice [8].
Recently, information and communication technologies (ICT) have been increasingly applied in the attempt to improve the level of autonomy and quality of life of elderly people at risk of falling, and a plethora of services were considered for fall prevention and detection, in the latter case, with the possibility to send alarms and call for rescue once falls have been detected [8,9].Technology-based interventions have been deployed in a wide range of contexts, and include: (i) diagnosing and treating fall risks [10,11]; (ii) increasing adherence to interventions [12,13]; (iii) detecting falls and alerting caregivers or next of kin [14,15].ICTs could also play a key role in enabling older adults to self-assess their fall risk, reducing costs and lessening the burden on the healthcare system, whilst also improving the quality and effectiveness of care provided [16].Despite the abundance of ICT systems, and the availability of several interesting implementations, e.g., [17][18][19][20][21], there are still several challenges that may potentially impact their use in practice [22].
This paper describes the design, development, and preliminary testing of a custom wearable sensing device and ICT service for fall detection and fall risk assessment as an element of the I-DONT-FALL platform for fall risk assessment and mitigation.The European project I-DONT-FALL (Integrated prevention and Detection sOlutioNs Tailored to the population and risk factors associated with FALLs, CIP-297225) aims at pursuing a multi-factorial approach to fall detection and fall risk assessment and mitigation.
The developed ICT service was based on two wearable smart sensors, called, respectively, WIMU fall detector and WIMU data-logger (Wearable Inertial Measurement Unit, WIMU); their goal was either to detect falls and promptly react in case of fall events, or to quantify fall risk instrumentally, in line with other proposed solutions [15][16][17][18].The WIMU fall detector was intended to be worn at the waist level for use during activities of daily living; the WIMU logger was intended for the quantitative assessment of tested individuals during the execution of clinical tests.Both devices provide their service in conjunction with an Android mobile device.
An interesting feature of the I-DONT-FALL approach is that the developed ICT services are intended to be used not only to automatically detect falls, as most competing solutions do, but also to prevent falls.Fall prevention is intended in this context to provide support to clinical decisions regarding the fall risk profile of patients, whose gait is assessed using wearable sensor technologies.In regard to the problem of fall detection, we have previously developed a method for pre-impact fall detection based on sensor fusion algorithms combining data from a waist-based inertial measurement unit integrating an air pressure sensor, [23].There, a thorough discussion of the advantages of using air pressure sensors in a fall detector was done, and our results were compared to those achieved by alternative implementations of state-of-the-art waist-based fall detectors.As for the preliminary testing of our approach concerning fall prevention, we describe in this paper our solution to the problem of getting an instrumental version of a widely used clinical test, namely the Six Minutes Walking Test (6MWT).
The 6MWT was administered to both high and low fall-risk patients wearing the proposed system at the waist level.Waist movement during walking plays a critical role in successful locomotion, and contributes to gait stability among older people [24].In the preliminary tests, the acquired signals were processed to extract gait parameters: stride time, cadence, stride time variability, root mean square of the vertical acceleration, and harmonic ratios (HR) of the three components of the acceleration.In fact, these gait variables, or a subset of them, have been previously considered in several research reports [25][26][27], sometimes with a specific focus on the study of falls [26].Another parameter of interest in 6MWT was the walked distance which was not computed using the WIMU sensor data, but was measured manually.Walked distance can be considered a proxy to walking speed, which can be estimated as the ratio between the distance and the time elapsed during the test.Recently, solutions have been proposed concerning the application of smartphone technology to the development of a practical and easy-to-use tool for rehabilitation professionals to use in the management of 6MWT [28].While a similar approach could have been considered here, we preferred to opt for the use of an external sensor unit, namely the WIMU.This was pursued with the aim of extending the number and type of gait variables that could be involved in the assessment (in particular, the HRs), and to be compliant with the experimental setups that are described in the literature [25,26,28].

The Overall ICT Solution
The I-DONT-FALL project aims at implementing a fall detection and risk management framework for a multi-factorial approach to risk assessment [29].The fall detection service is depicted in Figure 1.The patient wears a fall detector, namely a smart sensor that is capable of identifying fall-related impacts.When a fall event is detected, an alarm is issued via the Bluetooth (BT) connection between the fall detector and an Android device from which it is sent to a call center and to a repository of phone numbers and/or e-mail addresses (i.e., relatives and caregivers).The Android device automatically selects the channel (Wi-Fi and/or GPRS/3G-4G) over which the alarm is to be broadcast.The call center closes the loop by contacting the patient/caregiver to check on his/her conditions and to acquire context information about the fall event.Context information is added to the sensor data in order to provide a clear representation of the fall event even in the case of false positives.Sensing data corresponding to 2.5-s long windows that are centered around the fall time of occurrence are automatically stored on the smartphone and transferred to a secure server.The activation of the call center is based on machine-machine interaction provided by a web service.All the gathered data from different users in different locations are stored on a remote secure server.The web service structure information is provided by the SOAP (Simple Object Access Protocol) protocol.
Three general methods for read access to patient data on the secure server by a third-party healthcare system are provided: • access to HTML/Java streams that allow interactive, top-down browsing of patient data, using a unique, time-limited URL; • access to PDF format summary reports of the patient data covering a specified period of time, normally 28-day blocks; • subscription to specific types of low-level physiological data and interventions that have been recorded for or by the patient within the system.In a secondary loop, information about the fall event are uploaded to a secure server automatically by the smartphone and manually by the call center and clinical staff that are also allowed to access the information in the patient's record.

The Hardware
The fall detector is a battery-powered (3.7 V Li-polymer Rechargeable) device (Figure 2) intended to be worn around the waist (weight 100 g) during indoor daily activities; the battery life is about 20 h, and data from the internal sensors is sampled at a rate of 100 Hz.
The electronics of the fall detector embeds two stacked Printed Circuit Boards (PCBs) of identical size: the controller and the sensor board.The controller is a commercial device based on a 32-bit low-power ARM cortex M0 Core running at 48 MHz, 8 KB RAM, 32 KB FLASH: the NXP LPC11U24.The software running on the controller is developed using an online Software Development Kit (SDK) that supports a C/C++ programming environment including libraries for peripheral abstraction.
The sensor board is a two-layer PCB (Figure 3), specifically designed and developed to host a battery charger powered connecting the device to an USB port via its mini USB connector, a micro SD card slot for internal logging, a Bluetooth module (RN-42 by Roving Networks), and four sensors.In particular, one tri-axial accelerometer (BMA180 by Bosch Sensortec), one tri-axial gyroscope (ITG-3200 by InvenSense), one tri-axial magnetic sensor (HMC5883L by Honeywell), and a barometric pressure sensor (BMP085 by Bosch), all sample at a rate of 100 Hz.The sensor setup is shown in Table 1.In a secondary loop, information about the fall event are uploaded to a secure server automatically by the smartphone and manually by the call center and clinical staff that are also allowed to access the information in the patient's record.

The Hardware
The fall detector is a battery-powered (3.7 V Li-polymer Rechargeable) device (Figure 2) intended to be worn around the waist (weight 100 g) during indoor daily activities; the battery life is about 20 h, and data from the internal sensors is sampled at a rate of 100 Hz.In a secondary loop, information about the fall event are uploaded to a secure server automatically by the smartphone and manually by the call center and clinical staff that are also allowed to access the information in the patient's record.

The Hardware
The fall detector is a battery-powered (3.7 V Li-polymer Rechargeable) device (Figure 2) intended to be worn around the waist (weight 100 g) during indoor daily activities; the battery life is about 20 h, and data from the internal sensors is sampled at a rate of 100 Hz.
The electronics of the fall detector embeds two stacked Printed Circuit Boards (PCBs) of identical size: the controller and the sensor board.The controller is a commercial device based on a 32-bit low-power ARM cortex M0 Core running at 48 MHz, 8 KB RAM, 32 KB FLASH: the NXP LPC11U24.The software running on the controller is developed using an online Software Development Kit (SDK) that supports a C/C++ programming environment including libraries for peripheral abstraction.
The sensor board is a two-layer PCB (Figure 3), specifically designed and developed to host a battery charger powered connecting the device to an USB port via its mini USB connector, a micro SD card slot for internal logging, a Bluetooth module (RN-42 by Roving Networks), and four sensors.In particular, one tri-axial accelerometer (BMA180 by Bosch Sensortec), one tri-axial gyroscope (ITG-3200 by InvenSense), one tri-axial magnetic sensor (HMC5883L by Honeywell), and a barometric pressure sensor (BMP085 by Bosch), all sample at a rate of 100 Hz.The sensor setup is shown in Table 1.The electronics of the fall detector embeds two stacked Printed Circuit Boards (PCBs) of identical size: the controller and the sensor board.The controller is a commercial device based on a 32-bit low-power ARM cortex M0 Core running at 48 MHz, 8 KB RAM, 32 KB FLASH: the NXP LPC11U24.The software running on the controller is developed using an online Software Development Kit (SDK) that supports a C/C++ programming environment including libraries for peripheral abstraction.
The sensor board is a two-layer PCB (Figure 3), specifically designed and developed to host a battery charger powered connecting the device to an USB port via its mini USB connector, a micro SD card slot for internal logging, a Bluetooth module (RN-42 by Roving Networks), and four sensors.In particular, one tri-axial accelerometer (BMA180 by Bosch Sensortec), one tri-axial gyroscope (ITG-3200 by InvenSense), one tri-axial magnetic sensor (HMC5883L by Honeywell), and a barometric pressure sensor (BMP085 by Bosch), all sample at a rate of 100 Hz.The sensor setup is shown in Table 1.The logger is a battery -powered (3.7V Li-polymer Rechargeable) device (Figure 4) intended to be worn around the waist (weight: 90 g) during the execution of specific tests by the patients.The battery life is about 4 h.The logger electronics differ from the those of the fall detector only in the features of the controller.The controller is now a commercial device based on a 32-bit ARM cortex M3 core running at 96 MHz, 32 KB RAM, 512 KB FLASH: the NXP LPC1768.Basically, the difference between the NXP LPC1768 and the NXP LPC11U24 is in the power consumption and memory capabilities.Computational and memory capabilities are higher in this controller compared to those of the fall detector.The sensor board is identical to the one used for the fall detector.

The Fall Detector: Functionalities
The fall detector is designed to achieve a continuous-data monitoring for almost the full length of the day.Working in conjunction with an Android mobile device and according to the diagram of Figure 5, the fall detector provides the following functions:  The logger is a battery -powered (3.7V Li-polymer Rechargeable) device (Figure 4) intended to be worn around the waist (weight: 90 g) during the execution of specific tests by the patients.The battery life is about 4 h.The logger is a battery -powered (3.7V Li-polymer Rechargeable) device (Figure 4) intended to be worn around the waist (weight: 90 g) during the execution of specific tests by the patients.The battery life is about 4 h.The logger electronics differ from the those of the fall detector only in the features of the controller.The controller is now a commercial device based on a 32-bit ARM cortex M3 core running at 96 MHz, 32 KB RAM, 512 KB FLASH: the NXP LPC1768.Basically, the difference between the NXP LPC1768 and the NXP LPC11U24 is in the power consumption and memory capabilities.Computational and memory capabilities are higher in this controller compared to those of the fall detector.The sensor board is identical to the one used for the fall detector.

The Fall Detector: Functionalities
The fall detector is designed to achieve a continuous-data monitoring for almost the full length of the day.Working in conjunction with an Android mobile device and according to the diagram of Figure 5, the fall detector provides the following functions: The logger electronics differ from the those of the fall detector only in the features of the controller.The controller is now a commercial device based on a 32-bit ARM cortex M3 core running at 96 MHz, 32 KB RAM, 512 KB FLASH: the NXP LPC1768.Basically, the difference between the NXP LPC1768 and the NXP LPC11U24 is in the power consumption and memory capabilities.Computational and memory capabilities are higher in this controller compared to those of the fall detector.The sensor board is identical to the one used for the fall detector.

The Fall Detector: Functionalities
The fall detector is designed to achieve a continuous-data monitoring for almost the full length of the day.Working in conjunction with an Android mobile device and according to the diagram of Figure 5, the fall detector provides the following functions: • automatic fall detection-a built-in algorithm of fall detection identifies impacts that may be related to falls, generates and displays alarms, and sends them to the Android device using BT connectivity;  As highlighted in the flowchart in Figure 5, after the system start-up, the fall detector waits for commands coming from the Android device.After receiving a "Start" command, the sensing board is initialized and a control loop is activated with the purpose of sampling the accelerometer data, executing the fall detection algorithm, computing the AL index, and parsing of the commands coming from the mobile device.In case a fall event is detected, an alert message is sent to the mobile device and the WIMU is frozen in power standby.The commands available to the mobile device As highlighted in the flowchart in Figure 5, after the system start-up, the fall detector waits for commands coming from the Android device.After receiving a "Start" command, the sensing board is initialized and a control loop is activated with the purpose of sampling the accelerometer data, executing the fall detection algorithm, computing the AL index, and parsing of the commands coming from the mobile device.In case a fall event is detected, an alert message is sent to the mobile device and the WIMU is frozen in power standby.The commands available to the mobile device allow the control loop exiting for the WIMU standby (Stop command) and the collection of data about the battery level and the AL index (GetBatteryLevel and GetALIndex commands).
A detailed description of the fall detection and AL estimation algorithms are beyond the scope of this paper; they are reported in the technical deliverables of the I-DONT-FALL project [30].

The Data Logger: Functionalities
The main functionality of the logger is data acquisition and their transfer to the Android device.Namely, the logger collects raw data from the set of sensors embedded in the sensor board at a rate of 100 Hz in two different modes, see the flowchart in Figure 6: 1.
standalone mode-the data are stored in the internal memory of the device, which is capable of storing records lasting six minutes; 2.
continuous mode-the data are transferred sample-by-sample to the Android mobile device; the maximum duration of a data record will depend on the battery duration (about four hours) of the wearable device.Considering the sampling rate (100 Hz) and a sensory data frame length of 38 bytes, the max data length collected in four hours is about 60 MB.
Technologies 2018, 6, x 7 of 13 A detailed description of the fall detection and AL estimation algorithms are beyond the scope of this paper; they are reported in the technical deliverables of the I-DONT-FALL project [30].

The Data Logger: Functionalities
The main functionality of the logger is data acquisition and their transfer to the Android device.Namely, the logger collects raw data from the set of sensors embedded in the sensor board at a rate of 100 Hz in two different modes, see the flowchart in Figure 6: 1. standalone mode-the data are stored in the internal memory of the device, which is capable of storing records lasting six minutes; 2. continuous mode-the data are transferred sample-by-sample to the Android mobile device; the maximum duration of a data record will depend on the battery duration (about four hours) of the wearable device.Considering the sampling rate (100 Hz) and a sensory data frame length of 38 bytes, the max data length collected in four hours is about 60 MB.

The Android Mobile Device
The mobile device runs the WIMU manager, an app which is able to operate either the fall detector or the logger.The full system operationality relies on the integrity of wireless communication (BT, GSM/GPRS/3G-4G and/or IEEE 802.11 b/g/n).
All communications between the WIMUs and the mobile device are based on the SLIP protocol (Serial Line Internet Protocol).The WIMU manager incorporates an FTP server that allows the data to be transferred to a remote data server.
When working in fall detection mode, the WIMU manager consists of four threads which work in parallel to accomplish the following tasks: 1.
periodic check of the connection with WIMU; 2.
periodic check of the connection with the call-center; 3.
acquisition of the ADL index and WIMU's battery level; 4.
alarm management; a.
propagate the alarm to different recipients (see Table 2); b.
upload of acceleration data logged by the WIMU in a time window around the fall event.In case of connection failure or fall-detection, the Android device generates text and vocal messages.AL index and the WIMU battery level are continuously displayed on the main activity of the WIMU manager (Figure 7).

The Android Mobile Device
The mobile device runs the WIMU manager, an app which is able to operate either the fall detector or the logger.The full system operationality relies on the integrity of wireless communication (BT, GSM/GPRS/3G-4G and/or IEEE 802.11 b/g/n).
All communications between the WIMUs and the mobile device are based on the SLIP protocol (Serial Line Internet Protocol).The WIMU manager incorporates an FTP server that allows the data to be transferred to a remote data server.
When working in fall detection mode, the WIMU manager consists of four threads which work in parallel to accomplish the following tasks: 1. periodic check of the connection with WIMU; 2. periodic check of the connection with the call-center; 3. acquisition of the ADL index and WIMU's battery level; 4. alarm management; a. propagate the alarm to different recipients (see Table 2); b. upload of acceleration data logged by the WIMU in a time window around the fall event.
In case of connection failure or fall-detection, the Android device generates text and vocal messages.AL index and the WIMU battery level are continuously displayed on the main activity of the WIMU manager (Figure 7).When working in logger mode, the WIMU manager implements different functionalities: 1. the selection of standalone mode (the logging duration can be specified) or continuous mode; 2. acquisition of the WIMU battery level; 3. acquisition of the data collected by the WIMU (at the end of the experiment for the standalone mode, sample-by-sample in continuous mode); 4. calculation and displaying of the Fast Fourier Transform (FFT) of the data acquired by the WIMU during a diagnostic test data acquisition.This tool is useful to let the user periodically check the correct functionality of the instrument.

Instrumentation of the Six-Minutes Walking Test
To test the potentialities of the proposed technological solution, an instrumental version of the 6MWT has been proposed by measuring lower trunk accelerations using the WIMU, configured as a When working in logger mode, the WIMU manager implements different functionalities: 1.
the selection of standalone mode (the logging duration can be specified) or continuous mode; 2.
acquisition of the WIMU battery level; 3.
acquisition of the data collected by the WIMU (at the end of the experiment for the standalone mode, sample-by-sample in continuous mode); 4.
calculation and displaying of the Fast Fourier Transform (FFT) of the data acquired by the WIMU during a diagnostic test data acquisition.This tool is useful to let the user periodically check the correct functionality of the instrument.

Instrumentation of the Six-Minutes Walking Test
To test the potentialities of the proposed technological solution, an instrumental version of the 6MWT has been proposed by measuring lower trunk accelerations using the WIMU, configured as a wireless data-logger.In particular, the results of a preliminary experimental session involving elderly subjects are reported to better explicate the potentialities of the proposed technological solution.Two groups were tested for this preliminary evaluation of the hardware, involving a subset of the overall IDONTFALL dataset, including 25 high fall-risk and 25 age-matched low fall-risk patients respectively, grouped and selected by the clinical partners of the I-DONT-FALL project [31].The WIMU was mounted at the L3 spinous process (lower trunk) using a Velcro belt carefully placed in order to not restrict the subjects' movement.Subjects were asked to stand still in their upright posture for few seconds before starting the test.The 6MWT was administered along a corridor 32-m long (approximately) with two small cones on the floor to mark the start and end points of each trip.No specific instructions were given to the operators to calibrate the WIMU sensors; care was required in fixing the WIMU to the body to align the device local frame to the anatomical axes.Trunk linear accelerations were measured along the vertical (VT), anteroposterior (AP), and medio-lateral (ML) axes, sampled at 100 Hz.At the end of each test, collected data were uploaded to the Android smartphone via Bluetooth.
The first gait variable considered for the 6MWT assessment is the walking distance D, expressed in meters, and measured manually by the experimenter.Stride time, T, expressed in seconds, is the time elapsed from the first contact of the (right) leg with the ground to the next; stride time variability is computed from the coefficient of variation (COV, standard deviation divided by mean value ×100) of stride time, which quantifies variability while taking into account mean performance.These gait variables, and especially stride time variability, were considered in past studies [7].The issue of gait variability is challenging, since variability in motor function can be regarded either as a marker of impaired motor control or as a positive sign of system adaptation [32].Gait involves cycles that are characterized by regularity, but also balance components characterized by variability.Identifying such components, while taking into account noise random error, is a challenge.If random error is large, reliability will be low, and any variable will show large variability.Thus, variability caused by random error may be misinterpreted as an indicator of adaptability or impairment.The estimation of spatio-temporal gait parameters requires the detection of subsequent foot contacts (onset and end of stride cycles).Several studies have addressed the relationship between measured accelerations (on trunk, thigh, shank and foot) and spatio-temporal gait parameters.We adapted the method proposed by Zijlstra and Hof [25] for stride time determination.
The harmonic ratios (HRs) are dimensionless quantities that, as they are derived from body accelerations, offer insights into the underlying mechanisms of balance control during gait [33].HRs provide information on the ability of subjects to control their trunk smoothly during walking, providing an indication of whole-body balance and coordination (gait stability).We measure HRs in three directions, which allows us to exam directional responses.It can be speculated that movements in the ML direction during walking can be controlled differently than those in the AP plane, raising interesting questions concerning the ability of HRs to correlate with or predict falls.It is hypothesized that significantly lower HRs are found in unstable older adults (self-reported falls or unsteadiness) when compared to normal groups.Higher HRs indicate smoother and more stable trunk movement during gait [33].Typical AP and VT acceleration patterns of the lower trunk during walking exhibit two major acceleration peaks per stride, one for each step; thus, frequency decomposition through Fourier analysis yields a dominance of the second harmonic and subsequent even harmonics.The even harmonics for the AP and VT indicate the in-phase components of the signal, whereas the odd harmonics comprise the out-of-phase components (minimized in healthy gait).The HRVT and HRAP are calculated by dividing the even harmonics (summed amplitudes of the first 20 even harmonics) by the odd harmonics (summed amplitudes of the first 20 odd harmonics), with higher HRs being characteristic of healthy, stable gait.Conversely, the ML accelerations exhibit one acceleration peak per stride, resulting in dominance of the first harmonic and subsequent odd harmonics.Here, the odd harmonics are in-phase and even harmonics are out-of-phase.Therefore, the HRML is calculated from a ratio of the odd harmonics divided by the even harmonics.

Results
Table 3 shows the results of gait parameters estimation across the two tested groups.Statistically significant differences, obtained by applying an independent samples t-test, are marked with asterisks.In Table 4, the correlation matrix computed for the gait parameters from the high fall risk group is also reported.

Discussion
The main results achieved during the preliminary experimental tests reported in this study can be summarized in the two following points.First, high fall-risk patients' gait was slower (0.51 m/s vs. 0.78 m/s on average), more variable (according to the estimated stride time variability), and less stable (the AP and VT directions, i.e., frontal stability) than normal gait (normative values taken from available literature).Statistically significant differences between the two groups were obtained for walked distance, stride time, cadence, and vertical acceleration RMS.In general terms, and despite the limitations of comparing these results with studies based on different protocols and selection criteria for the subjects, this is in accordance with previous studies that identified statistically significant reduced stride length and walking speed in high fall risk patients [26].In our solution, the differences observed for stride time variability and harmonic ratios is not as high as it was observed to be in previous studies [28,34]; we believe that this could be an effect of the limited pool of tested subjects in this preliminary evaluation of the device.
Secondly, the results of the correlation analysis show the presence of a remarkably strong relationship between walked distance, stride time variability, and frontal stability, in the sense that a fast gait is likely to be less variable and more frontally stable than a slower pathologic gait.Such results confirmed the expectations and previous findings concerning gait subjects at high risk of falls, and in our view, confirmed the applicability of the proposed solution to the specific scenario of fall risk assessment in the elderly.

Conclusions
The proposed technological solution makes up part of the integrated solution for fall detection and fall risk assessment and mitigation as proposed in the I-DONT-FALL EU-funded project.The WIMU fall detector accomplished the aim of monitoring falls during daily life, allowing a full day's battery life and embedding custom-made fall detection algorithms.Moreover, the fall detector allowed the logging of fall data, which is useful for updating the existing fall detection computational solutions using real falls data.The designed WIMU data logger consisted of a fully functional logging unit that accurately and reliably logged data and implemented gait parameter estimation, embedding the processing in the unit.
Finally, it is worth noting that, the proposed solution for fall risk assessment and fall detection is fully integrated in an ICT solution aiming at a multi-factorial approach to risk assessment and at prompting intervention protocol in case of fall.Such a solution, the final result of the I-DONT-FALL project, achieved a commercially-ready integrated framework for both monitoring the elderly at home and reducing their fall risk by prescribing physical and cognitive activities tailored to the user.

Figure 1 .
Figure 1.Fall detection service architecture: in case of an alarm by the WIMU fall detector, accelerometer data and the alarm itself are sent to the smartphone by Bluetooth connection.The smartphone automatically sends warning messages to a list of recipients (SMS/email) and alerts the call center that directly contacts the elderly individual on the smartphone, and if needed, clinical emergency staff.In a secondary loop, information about the fall event are uploaded to a secure server automatically by the smartphone and manually by the call center and clinical staff that are also allowed to access the information in the patient's record.

Figure 2 .
Figure 2. The WIMU fall detector case with its dimensions in different views (units in mm).

Figure 1 .
Figure 1.Fall detection service architecture: in case of an alarm by the WIMU fall detector, accelerometer data and the alarm itself are sent to the smartphone by Bluetooth connection.The smartphone automatically sends warning messages to a list of recipients (SMS/email) and alerts the call center that directly contacts the elderly individual on the smartphone, and if needed, clinical emergency staff.In a secondary loop, information about the fall event are uploaded to a secure server automatically by the smartphone and manually by the call center and clinical staff that are also allowed to access the information in the patient's record.

Figure 1 .
Figure 1.Fall detection service architecture: in case of an alarm by the WIMU fall detector, accelerometer data and the alarm itself are sent to the smartphone by Bluetooth connection.The smartphone automatically sends warning messages to a list of recipients (SMS/email) and alerts the call center that directly contacts the elderly individual on the smartphone, and if needed, clinical emergency staff.In a secondary loop, information about the fall event are uploaded to a secure server automatically by the smartphone and manually by the call center and clinical staff that are also allowed to access the information in the patient's record.

Figure 2 .
Figure 2. The WIMU fall detector case with its dimensions in different views (units in mm).Figure 2. The WIMU fall detector case with its dimensions in different views (units in mm).

Figure 2 .
Figure 2. The WIMU fall detector case with its dimensions in different views (units in mm).Figure 2. The WIMU fall detector case with its dimensions in different views (units in mm).

Figure 4 .
Figure 4.The WIMU logger case with its dimensions in different views (units in mm).

Figure 4 .
Figure 4.The WIMU logger case with its dimensions in different views (units in mm).

Figure 4 .
Figure 4.The WIMU logger case with its dimensions in different views (units in mm).

13 
• automatic logging (and subsequent transfer to the Android device)-acceleration data occurring in a time window around the fall event are stored; this is a useful feature to keep track of fall events and use the logged data for post-hoc processing, e.g., further refinement and tuning of the built-in fall detection algorithm; • parsing and managing of a list of commands coming from the mobile device to change the parameters of the algorithms, obtain battery information, and troubleshoot possible device errors.• estimation of the activity level (AL)-the built-in algorithm of AL estimation helps keep track of the intensity of the physical activity of the patient during the day.Technologies 2018, 6, x 6 of automatic fall detection-a built-in algorithm of fall detection identifies impacts that may be related to falls, generates and displays alarms, and sends them to the Android device using BT connectivity;  automatic logging (and subsequent transfer to the Android device)-acceleration data occurring in a time window around the fall event are stored; this is a useful feature to keep track of fall events and use the logged data for post-hoc processing, e.g., further refinement and tuning of the built-in fall detection algorithm;  parsing and managing of a list of commands coming from the mobile device to change the parameters of the algorithms, obtain battery information, and troubleshoot possible device errors. estimation of the activity level (AL)-the built-in algorithm of AL estimation helps keep track of the intensity of the physical activity of the patient during the day.

Table 2 .
Android mobile device fall detection alarm management.Tick marks indicates the used

Table 3 .
Gait parameters results for the two groups.

Table 4 .
Correlation matrix computed for the gait parameters from the high fall risk group.In bold: the strongest correlations among gait parameters.