EP3796282A2 - Dispositif, système et procédé de détection de chute - Google Patents

Dispositif, système et procédé de détection de chute Download PDF

Info

Publication number
EP3796282A2
EP3796282A2 EP20188159.6A EP20188159A EP3796282A2 EP 3796282 A2 EP3796282 A2 EP 3796282A2 EP 20188159 A EP20188159 A EP 20188159A EP 3796282 A2 EP3796282 A2 EP 3796282A2
Authority
EP
European Patent Office
Prior art keywords
fall detection
detection device
data
fall
sensor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP20188159.6A
Other languages
German (de)
English (en)
Other versions
EP3796282A3 (fr
Inventor
Cristina Soaz González
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qolware GmbH
Original Assignee
Qolware GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qolware GmbH filed Critical Qolware GmbH
Publication of EP3796282A2 publication Critical patent/EP3796282A2/fr
Publication of EP3796282A3 publication Critical patent/EP3796282A3/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00—Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G08B21/02—Alarms for ensuring the safety of persons
    • G08B21/04—Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons
    • G08B21/0407—Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons based on behaviour analysis
    • G08B21/043—Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons based on behaviour analysis detecting an emergency event, e.g. a fall
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00—Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G08B21/02—Alarms for ensuring the safety of persons
    • G08B21/04—Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons
    • G08B21/0438—Sensor means for detecting
    • G08B21/0446—Sensor means for detecting worn on the body to detect changes of posture, e.g. a fall, inclination, acceleration, gait
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00—Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G08B21/02—Alarms for ensuring the safety of persons
    • G08B21/04—Alarms for ensuring the safety of persons responsive to non-activity, e.g. of elderly persons
    • G08B21/0438—Sensor means for detecting
    • G08B21/0453—Sensor means for detecting worn on the body to detect health condition by physiological monitoring, e.g. electrocardiogram, temperature, breathing

Definitions

  • the present invention generally relates to a device, system and method for activity monitoring, more precisely a device, system and method for fall detection.
  • a well-known solution is to provide an alarm button that may be worn by the elderly person, who can trigger an alarm signal by pushing the button in case of a fall.
  • a person might be immobile due to injuries or even unconscious and thus unable to push the button.
  • the present invention relates to a fall detection device.
  • the fall detection device comprises at least one status sensor, configured to at least sense if the fall detection device is worn and provide corresponding data, at least one movement sensor, configured to generate data on the movement and/or orientation of the fall detection device, and at least one ambient sensor, configured to generate data on the ambient conditions of the fall detection device.
  • the present invention relates to a device for detecting a fall of the user, wherein the fall detection device comprises at least 3 different sensors.
  • the status sensor may sense if a device is worn which may be advantageous to rule out events wherein the fall detection is falling down when not being worn, for example from a table to the floor.
  • the movement sensor may detect the movement and or orientation of the device.
  • the ambient sensor may provide data on ambient conditions, for example temperature, pressure and/or altitude. This may be advantageous as it may further improve the accuracy of the fall detection. Further, it may for example provide valuable context for the calculation of the certainty of a fall occurrence.
  • such a fall detection device may enable a more reliable detection of falls of the user, i.e. it may reduce false positives and/or false negatives. This may be advantageous as it may reduce false alarms being send for example to care takers or family members of the user and for example increase the security of the user.
  • the fall detection device may be configured to be a wearable device, that is the fall detection device may be configured to be worn by a user. This may be advantageous as it may enable the user to take the fall detection to any location, i.e. it may be flexible. Additionally, the fall detection device can be configured to be worn around the wrist, e.g. in the form of a wristwatch. This may further be advantageous as a wristwatch may be easily accessible and comfortable to wear. Moreover, a fall detection device worn around the wrist may for example provide further functionality, such as the functionality of a watch, a smart watch, a health monitor and/or fitness tracker.
  • the at least one status sensor of the fall detection device may be at least one of a proximity sensor, configured to sense any object in close proximity, a heart rate sensor, configured to generate data on the users heart rate (HR), and a pulse oximeter, configured to generate data on the user's oxygen saturation and HR.
  • a proximity sensor configured to sense any object in close proximity
  • a heart rate sensor configured to generate data on the users heart rate (HR)
  • HR heart rate
  • a pulse oximeter configured to generate data on the user's oxygen saturation and HR.
  • the status may for example also be determined by the presence (or absence) of a vital sign.
  • This may be advantageous, as the presence of a vital sign may be a more reliable signal compared to a proximity sensor which only senses the presence of an object in close proximity.
  • a vital sign may be much harder to accidentally (or purposefully) generate without the fall detection device being worn. Again, this may be advantageous, as a fall may only be detected if the fall detection device is worn and thus providing a reliable status sensor may reduce the number of false alarms, e.g., as a result of the device falling on the floor without being worn.
  • the ambient sensor of the fall detection device may be an altimeter, configured to generate data on changes in altitude. This may be advantageous as a fall typically comprises a change in altitude, thus sensor data may provide a further indication if a fall has happened or not.
  • the altimeter may comprise a barometric pressure sensor configured to generate data on changes in the barometric pressure. Additionally, the altimeter may comprise a temperature sensor configured to generate data on the ambient temperature. This may be beneficial as the barometric pressure may also depend on the ambient temperature; thus, it may provide the means to estimate the altitude more precisely by also considering the ambient temperature.
  • the fall detection device may comprise a proximity sensor configured to sense objects in close proximity and provide corresponding data. Such a proximity sensor may therefore indicate if the device is worn.
  • a proximity sensor located on the inside of a wristwatch may sense the skin of the user when being worn, i.e. it may sense an object in close proximity which may indicate that the device is worn.
  • the fall detection device may comprise a heart rate sensor, configured to generate data on the heart rate (HR) of a user.
  • the heart rate sensor can be at least one of an electrocardiography (ECG) sensor and a photoplethysmography (PPG) sensor.
  • ECG electrocardiography
  • PPG photoplethysmography
  • the heart rate sensor may provide data on the heart rate of the user and/or through monitoring the sensor data determine if a vital sign is present as indication that the device is being worn.
  • the fall detection device may comprise a pulse oximeter configured to generate data on the HR and oxygen saturation of the user.
  • the pulse oximeter may also be a photoplethysmography (PPG) sensor, i.e. the sensor may sometimes be configured to generate data on the HR and oxygen saturation of the user.
  • PPG photoplethysmography
  • Knowledge of the oxygen saturation may provide a further indication of a fall of the user and/or may for example provide information on the severity of the fall and/or the user's condition.
  • the at least one movement sensor may be at least one of an accelerometer, configured to generate data on a physical acceleration of the fall detection device, a gyroscope, configured to generate data on an orientation of the fall detection device, and a magnetometer, configured to generate data on the orientation of the fall detection device. That is, the accelerometer may generate data on the physical acceleration of the device in at least one direction, preferably in three directions that are perpendicular to each other. The gyroscope and/or magnetometer may be configured to generate data on the orientation of the fall detection device within the three-dimensional space.
  • the fall detection device may comprise a memory, configured to store data and computer program code.
  • the memory may comprise at least one non-volatile storage device (e.g. a solid-state drive (SSD)) and/or at least one volatile storage device (e.g. random-access memory (RAM)).
  • SSD solid-state drive
  • RAM random-access memory
  • the fall detection device may comprise a processing unit, configured to operate the fall detection device.
  • the processing unit may comprise at least one microprocessor, such as a central processing unit (CPU) and/or at least one circuit, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), etc.
  • CPU central processing unit
  • ASIC application specific integrated circuit
  • FPGA field-programmable gate arrays
  • the processing unit may be configured to acquire data from at least one of the sensors continuously, at specified intervals or based on specific events. This may be advantageous for reducing the power consumption of the fall detection device.
  • the times at which data is acquired may vary for each sensor. For example, some sensor data may only be acquired in consequence to sensor data acquired (and potentially processed) form different sensors.
  • the processing unit may be configured to pre-process at least a subset of the acquired data.
  • the processing unit may pre-process the sensor data from the barometric pressure sensor and the temperature sensor to express the sensor data in terms of altitude.
  • the processing unit may further be configured to store at least a subset of the acquired and/or pre-processed data in the memory at specified intervals, continuously or based on specific events.
  • the processing unit may further be configured to process at least a subset of the acquired, pre-processed and/or stored sensor data. For example, it may be configured to extract statistical values, such as an average or a deviation, from at least a subset of the sensor data. Additionally or alternatively, the processing unit may be configured to run a fall detection algorithm to identify fall events, wherein the input is at least a subset of the sensor data. That is, the acquired, pre-processed, processed and/or stored sensor data.
  • the processing unit may be configured to process at least a subset of the sensor data and/or run a fall detection algorithm with the aim of identifying fall events of the user. That is, based on the sensor data the processing may, through data processing and/or running of a fall detection algorithm identify potential fall events of the user.
  • the fall detection algorithm may further be configured to estimate the severity of a fall event based on at least a subset of the sensor data. This may be advantageous as for example different actions may be taken depending on different severity levels of the fall. For example, in case of a very severe fall an alarm may be directly send professional emergency services, whereas for a less severe fall only a family member may be contacted.
  • machine-readable program code may be stored in the memory, which may be configured to cause the processing unit to execute tasks and steps required to operate the fall detection device when executed on the processor or circuit.
  • the fall detection device may further comprise a user interface, configured to enable interactions with the user. This may be advantageous as it may for example provide the user with information, enable the user to modify settings and/or receive feedback from the user.
  • the user interface may comprise a screen, wherein the screen may be a touch screen.
  • the touch screen may further be configured to be pressure sensitive, i.e. the screen can distinguish between different levels of force. This may be beneficial as it may allow to provide different functionality of the user interface to the user, depending on the applied pressure.
  • the screen may be configured to adjust the level of brightness. This may be advantageous for reducing the power consumption, for example by reducing the level of brightness of the screen in low light situations.
  • the fall detection device may further comprise an ambient light sensor, configured to generate data on the illuminance.
  • the screen may be configured to adjust the brightness according to the ambient light sensor data.
  • the user interface may comprise at least one physical button configured to execute a predetermined action when actuated by the user. Additionally or alternatively, the user interface may comprise at least one virtual button configured to execute a predetermined action when actuated by the user.
  • a virtual button may for example be a button displayed on a touch screen, or a gesture detected though at least one sensor of the fall detection device, e.g., a certain movement registered by the movement sensor, such as tapping the fall detection device three times,
  • the predetermined action executed when the physical or virtual button is actuated may be one of triggering an alarm and aborting an alarm.
  • the predetermined action may depend on the alarm status of the fall detection device. For example, if the fall detection device has detected a fall based on at least a subset of the sensor data and subsequently triggered an alarm, the user may abort the alarm by actuating the corresponding physical or virtual button. Alternatively, if a user for example fell and the device did not register the fall, the user may still trigger an alarm by actuating the same button.
  • processing unit may be configured to control the user interface.
  • the fall detection device may comprise a communication unit, configured to communicate with external devices.
  • the communication unit can comprise at least one of a Subscriber Identity Module (SIM card) and an embedded SIM (eSIM). Further, the communication unit may comprise at least one of a modem and a network device.
  • SIM card Subscriber Identity Module
  • eSIM embedded SIM
  • the communication unit may be configured to exchange data with a server via cellular and/or wireless networks.
  • the communication unit may send sensor data to a remote server, which may for example further analyse the data, or provide a subset of the data to a third party such as an emergency service.
  • the communication unit may be configured to establish a two-way communication between the fall detection device and another device such as a smartphone. That is, the fall detection device can for example establish and receive calls.
  • the communication unit may be configured to communicate and exchange data via a wireless personal area network (WPAN), such as Bluetooth®, ANT+ or ZigBee. Additionally or alternatively, the communication unit may be configured to communicate and exchange data via a low power wide area network (LPWAN), such as a Long Range Wide Area Network (LoRaWAN) or SigFox.
  • WPAN wireless personal area network
  • LPWAN low power wide area network
  • LiRaWAN Long Range Wide Area Network
  • SigFox SigFox
  • the communication unit may be configured to communicate with digital assistants, such as voice assistants, e.g. Alexa, Siri or Google Assistant. Further, the communication unit may be configured to communicate with smart home devices.
  • digital assistants such as voice assistants, e.g. Alexa, Siri or Google Assistant.
  • the communication unit may be configured to communicate with smart home devices.
  • the processing unit may be configured to send and receive processing instructions, sensor data, operational data, or the like via the communication unit.
  • the fall detection device may further comprise a battery, configured to power the fall detection device.
  • the battery may be removable. This may be advantageous for exchanging the battery, e.g., to keep the fall detection device ready for use.
  • the battery may comprise a capacity of at least 100mAh, preferably at least 300 mAh, even more preferably at least 500 mAh.
  • the battery may be rechargeable.
  • the fall detection device may be configured to recharge the battery wirelessly, e.g. through electromagnetic induction. Additionally or alternatively, the fall detection device may comprise a connector configured to receive a cable for a wired connection.
  • the connector may comprise a magnetic component. This may be advantageous for establishing a good connection between the connector and the device.
  • the connector may be configured to recharge the battery.
  • the connector is configured to communicate with external devices, e.g. via a Universal Serial Bus (USB) connection.
  • USB Universal Serial Bus
  • the processing unit may be configured to manage the power consumption of the device. This may be advantageous to prolong the time the fall detection device may be utilized without recharging.
  • the fall detection device may be configured to run for at least 1 day, preferably at least 3 days, more preferably at least 7 days without recharging or changing the battery.
  • the fall detection device can comprise at least one position sensor configured to determine and provide data on the position based on a global navigation satellite system, such as GPS or Gallileo. This may be advantageous when a user experiences a fall and requires help. In such situations the position may be determined and for example shared with an emergency service or a family member of the user.
  • a global navigation satellite system such as GPS or Gallileo.
  • the fall detection device may comprise a microphone, configured to generate data on an acoustic signal.
  • the microphone may be configured to generate data on acoustic signals within at least part of the audible frequency range of humans, i.e. within at least part of 20 Hz to 20 kHz, such as 50 Hz to 10 kHz. Additionally or alternatively, the microphone may be configured to generate data on acoustic signals in at least part of the ultrasonic frequency range, i.e. frequencies exceeding 20 kHz, such as 20 kHz to 50 kHz. This may be advantageous for distance detection through sending and detecting of ultrasonic pulses.
  • the fall detection device may comprise a loudspeaker, configured to produce sounds.
  • the loudspeaker may be configured to produce sounds within at least part of the audible frequency range of humans, i.e. within at least part of 20 Hz to 20 kHz, such as 50 Hz to 10 kHz. Additionally or alternatively, the loudspeaker may be configured to produce sounds within at least part of the ultrasonic frequency range, i.e. frequencies exceeding 20 kHz, such as 20 kHz to 50 kHz. Again, this may be advantageous for distance detection through sending and detecting of ultrasonic pulses.
  • the fall detection device may further comprise a blood sugar sensor, configured to generate data on the blood glucose level of the user.
  • the fall detection device may further comprise a blood pressure sensor, configured to generate data on the blood pressure of the user.
  • the fall detection device may further comprise a temperature sensor, configured to generate data on at least one of the ambient temperature and the body temperature of the user.
  • the additional sensors may provide further information for detecting fall events. Further they may for example provide data for estimating a probability for a fall of the user and/or data to estimate the severity of a fall event. Further, some data may for example be provided to emergency services or family members of the user to support them making evidence-based decisions about the actions needed to better help the user particularly in case of a fall.
  • the fall detection device may further comprise a haptic feedback unit configured to provide a haptic feedback to the user, e.g. in case of an alarm.
  • the haptic feedback unit may comprise at least one vibration motor configured to provide vibrations as feedback to the user. This may be advantageous for getting the users attention, for example if an alarm is triggered.
  • the fall detection device may be configured to connect to an external handheld device, such as a smartphone. Additionally, the fall detection device may be configured to be utilized as user interface for the handheld device, i.e. enable input to and output from the handheld device. Further, the fall detection device may be configured to display content from the external handheld device, such as messages, (push) notifications, applications or controls for applications, etc.
  • the fall detection device may comprise a radar sensor configured to generate data on a distance.
  • the fall detection device may further comprise an electrodermal activity sensor configured to measure the skin conductance. This may be advantageous as it may for example be indicative of the activity of the sympathetic nervous system and/or provide an indication for the hydration of the user, which may be particularly relevant for the elderly.
  • the present invention relates to a fall detection system for identifying a fall and triggering an alarm, the fall detection system comprising a fall detection device as described above.
  • the fall detection system may further comprise at least one external sensor, configured to provide additional data, e.g. on the vital signs or weight of a user.
  • a fall detection system may comprise a fall detection device and further at least one external sensor, e.g. a scale, an external heart rate monitor or a blood sugar sensor. This may be advantageous, as it may provide the system with sensor data of sensors that may for example not easily be incorporated in the fall detection device itself.
  • the fall detection device may be configured to communicate with and receive data from the external sensors via a wired or wireless connection.
  • the external sensors can be configured to communicate and exchange data via a wireless personal area network (WPAN), such as Bluetooth® or ANT+, and/or a wireless local area network (WLAN). This may enable reliable, fast and/or user-friendly transmission of data between the fall detection device and the at least one external sensor.
  • WPAN wireless personal area network
  • WLAN wireless local area network
  • the external sensors may comprise at least one of a blood sugar sensor, configured to generate data on the blood glucose level the user, a blood pressure sensor, configured to generate data on the blood pressure of the user, an ECG sensor, configured to generate data on the HR and the heart's electrical activity of the user, a pulse oximeter, configured to generate data on the HR and oxygen saturation of the user, a scale, configured to generate data on at least the weight of a user, and a blood coagulometer, configured to generate data on the coagulation efficiency of the user's blood.
  • a blood sugar sensor configured to generate data on the blood glucose level the user
  • a blood pressure sensor configured to generate data on the blood pressure of the user
  • an ECG sensor configured to generate data on the HR and the heart's electrical activity of the user
  • a pulse oximeter configured to generate data on the HR and oxygen saturation of the user
  • a scale configured to generate data on at least the weight of a user
  • a blood coagulometer configured to generate data on the coagulation efficiency of the user's blood
  • the fall detection system may further comprise a professional service, such as a professional service provider, an emergency service or call centre.
  • the fall detection system may comprise at least one emergency contact, such as a family member or a friend.
  • the fall detection device may be configured to directly send an alarm to the professional service and/or emergency contacts, e.g. family members, friends etc. This may be advantageous as the alarm may for example be send automatically, that is without any further interaction with the user, which may particularly be beneficial if the user got injured in a fall event.
  • the fall detection system may further comprise a remote server, also referred to as server.
  • the server may be configured to communicate and exchange data with the fall detection device. Additionally, the server may be configured to store data received from the fall detection device.
  • the fall detection device may be configured to send an alarm to the server. Additionally, the server may be configured to, upon receiving an alarm from the fall detection device, send an alarm to at least one third party, such as a professional service or an emergency contact. That is in some embodiments an alarm may first be send to the server and not directly to the professional service and/or emergency contact.
  • a third party such as a professional service or an emergency contact. That is in some embodiments an alarm may first be send to the server and not directly to the professional service and/or emergency contact.
  • the server may be configured to store data on past manually or automatically triggered or aborted alarms and at least a subset of the corresponding sensor data. Further, the server may be configured to store sensor data not corresponding to a triggering or aborting of an alarm, e.g. sensor data corresponding to specific activities or standard routines or a stumble of the user. Generally, the stored data may be beneficial for improving the fall detection algorithm, e.g. for personalizing the fall detection algorithm to a specific user. Moreover, the sensor data may also provide insights for healthcare providers, and or family and friends. For example, it may indicate a long-term decline of physical activity or it may enable association of particular activities with a higher risk of falling.
  • the remote server may at least be one of a dedicated server, a cloud-based server or any combination thereof, e.g. a dedicated server with additional cloud-based storage.
  • the present invention relates to a method.
  • the method comprising a fall detection system as described above, wherein the method comprises collecting sensor data from a plurality of the sensors of the fall detection system, determining the device status, i.e. if the fall detection device is worn by the user, based on data from at least one status sensor, utilizing a fall detection algorithm to determine if a fall has happened or not based on at least a subset of the sensor data, and triggering an alarm if a fall event is detected.
  • the step of collecting the sensor data may comprise pre-processing at least part of the sensor data. Further, the step of collecting sensor data may comprise storing at least part of the (pre-processed) sensor data in the memory.
  • the sensor data may be collected repeatedly, wherein the frequency at which the sensor data is collected may be specific to each sensor.
  • the data of the movement sensor may be collected repeatedly with a frequency in the range of 0.1 Hz to 1kHz, preferably in the range of 1 Hz to 500 Hz, more preferably in the range of 1 Hz to 100 Hz, such as 50 Hz.
  • the device status may be determined by analysing the data of one or a plurality of status sensors. For example, sensor data from a proximity sensor and/or a heart rate sensor. It will be understood that the heart rate data may also be utilized for the fall detection, i.e. the HR data may also be utilized as indication of a fall of the user. Further, the device status may be determined repeatedly with a frequency in a range of 100 mHz to 1 kHz, preferably 500 mHz to 100 Hz, such as 1 Hz.
  • determining the device status may be part of the fall detection algorithm.
  • the device status may also be determined as part of the fall detection algorithm whereas in other embodiments it may determined separately form the fall detection algorithm. In the latter case, the fall detection algorithm may for example only executed when the device is worn.
  • the fall detection algorithm may comprise at least one or a plurality of one or more steps of comparing at least a subset of the collected sensor data to pre-defined thresholds, and one or more steps of classifying a feature set and/or raw data derived from at least a subset of the collected sensor data, to determine if a fall has happened or not.
  • the step of classifying a feature set may be based on statistical or machine learning methods.
  • the collected sensor data may comprise data from at least one status sensor, data from at least one movement sensor, and data from at least one ambient sensor.
  • the data from the at least one status sensor may comprise HR data from a HR sensor. Additionally or alternatively, the data from the at least one status sensor may comprise data from a proximity sensor. Further, the data from at least one status sensor may comprise HR data and/or oxygen saturation data from a pulse oximeter.
  • the data from at least one movement sensor may comprise acceleration data from at least one accelerometer and/or orientation data from a gyroscope. Additionally or alternatively, the data from at least one movement sensor may comprise data from a magnetometer.
  • the data from the at least one ambient sensor may comprise barometric pressure data from a barometer. Additionally or alternatively, the data from at least one ambient sensor may comprise illuminance data form an ambient light sensor and/or temperature data from at least one temperature sensor. Further, the data from the at least one ambient sensor may comprise acoustic signal data from a microphone.
  • the collected data may comprise blood pressure data from at least one blood pressure sensor and/or blood glucose level data from a blood sugar sensor. Additionally or alternatively, the collected data may comprise distance data from a radar sensor.
  • the fall detection algorithm may comprise estimating the severity of a fall based on at least a subset of the sensor data.
  • the step of triggering an alarm may comprise a de-escalation phase enabling the user to abort an alarm. This may be advantageous as it may enable the user to abort an alarm., e.g., in case the user recovered quickly from the fall or no fall happened (false positive).
  • the de-escalation phase may comprise providing a visual feedback, such as a countdown showing the time remaining to abort the alarm on the screen of the fall detection device. Further, the de-escalation phase may comprise providing an audio feedback and/or a haptic feedback.
  • the de-escalation phase may comprise a length and the length of the de-escalation phase may be in a range of 0 s to 20 s, preferably 0 s to 10 s.
  • the length of the de-escalation phase may depend on the estimated severity of the fall event. For example, for a very severe fall the de-escalation phase may be shorter than for a less severe fall to ensure that help will be provided to the user as soon as possible in case of a very severe fall.
  • the alarm may be aborted through manual input to the user interface, e.g. by voice command, actuating a physical or virtual button or through a touch screen.
  • the communication unit may establish two-way communication between the fall detection device and another device such as a smartphone, e.g. in case of a fall or based on a user input.
  • the alarm may further be triggered manually through an input to the user interface, e.g. by voice command, pressing a physical or virtual button or through a touch screen.
  • triggering an alarm may comprise an escalation phase.
  • the escalation phase may follow the de-escalation phase in case the alarm is still active, i.e. it was not aborted during the de-escalation phase.
  • the escalation phase may comprise sending an alarm message to at least one of a professional service and an emergency contact.
  • the loudspeaker may generate a sound to draw attention during the escalation phase, e.g. a loud alarm signal or a call for help.
  • the escalation phase may comprise establishing a call with at least one of a professional service and an emergency contact. Further, the escalation phase may comprise establishing a call using the microphone and the loudspeaker of the fall detection device to enable hands-free operation.
  • the method may comprise determining the device position and generating position data through at least one of collecting data from the at least one position sensor, localizing the device utilizing the method of a Wi-Fi positioning system, e.g. WLAN fingerprinting or triangulation, localizing the device through the Global System for Mobile Communications (GSM), localizing the device utilizing Bluetooth beacons, or any combination thereof.
  • a Wi-Fi positioning system e.g. WLAN fingerprinting or triangulation
  • GSM Global System for Mobile Communications
  • the alarm message may comprise information on the fall event, e.g. time or estimated severity. Additionally or alternatively, the alarm message may further comprise user information, e.g. a user ID, name or medical history. This may be advantageous, as the professional service or emergency contact may thus tailor the response to the action based on the data received. For example, a professional service may check the medical history of a user and for example take into account known diseases of the user.
  • the alarm message may further comprise position data, e.g. from a position sensor, derived from the cellular network or a known WLAN. This may be advantageous for quickly finding the user in case of a fall, e.g., if the user is unconscious or does not remember his current location.
  • the alarm message may further comprise sensor data, e.g. HR, oxygen saturation, blood pressure or blood glucose level. This may be beneficial for judging the current health status of the user and taking the required actions. For example, it may allow the receiver of an alarm message to judge if a professional emergency service is required based on some of the vital signs of the user.
  • sensor data e.g. HR, oxygen saturation, blood pressure or blood glucose level.
  • the fall detection algorithm may be trained and updated based on a database of past manually or automatically triggered or aborted alarms and at least a subset of the corresponding sensor data. This may be advantageous for improving the performance of the fall detection device, i.e. it may for example reduce occurrence of false positives and false negatives in the process of detecting potential fall events.
  • the fall detection algorithm may be trained and updated based on a database of past manually or automatically triggered or aborted alarms and the corresponding sensor data that is specific to a group of users, e.g. defined by age, activity level or pre-existing conditions.
  • the fall detection algorithm may be personalized based on a database of past manually or automatically triggered or aborted alarms and the corresponding sensor data, wherein the database is specific to the user.
  • the database may further contain sensor data not corresponding to a triggering or aborting of an alarm, e.g. sensor data corresponding to specific activities or standard routines. This may be beneficial for training of the fall detection algorithm since some activities may lead to sensor data very similar to fall events, e.g. going down stairs or taking an elevator. Thus, the fall detection may be trained to better distinguish such activities from actual fall events.
  • the input to the fall detection algorithm may further comprise information on ambient conditions, i.e. the algorithm may be context aware.
  • the fall detection algorithm may be adaptive, that is it may change e.g. depending on ambient conditions or physical activity of the user. For example, the algorithm may take into account current weather and/or lighting conditions when checking for potential fall events of the user. This may further improve the performance of the fall detection algorithm.
  • the method may comprise receiving user input through the user interface, e.g. for changing device settings or updating user information.
  • the method may further comprise receiving feedback following the detection of a fall event, e.g. confirmation that a fall happened or feedback on the severity of a fall by the user, a family member, a care taker, etc.
  • the method may comprise triggering different events depending on the pressure applied to the pressure sensitive touch screen.
  • the touch screen may be force sensitive such that depending on the applied force different actions may be triggered.
  • collecting the sensor data may comprise determining the acceleration of the device in all three dimensions, and separating the acceleration data into static (gravity) acceleration and dynamic (linear) acceleration by means of a low-pass filter. Further, collecting the sensor data may comprise determining an orientation angle of the device with respect to the vertical axis defined by the gravity component, i.e. static acceleration. The angle may for example be estimated by comparing the measured static acceleration to the expected gravitational component.
  • the fall detection device comprises a gyroscope
  • collecting the sensor data may comprise determining the orientation angle of the fall detection device. This may be advantageous as a gyroscope may enable more precise determination of the orientation of the device. Further, the method may comprise combining the orientation data obtained by the accelerometer and the gyroscope.
  • the method may further comprise determining the orientation angle of the device for a set time interval I1, wherein the length of the time interval I1 may be in a range of 1 s to 20 s, preferably 4s to 10 s, such as 6 s.
  • collecting the sensor data may comprise detecting the ambient pressure and deducing the corresponding altitude. Further, deducing the altitude corresponding to the ambient pressure can be supported by current weather data and/or position data. This may be beneficial as it may improve the accuracy of deducing the altitude. Further, collecting the sensor data of the altimeter may comprise storing the raw barometric pressure and/or the deduced altitude.
  • the method can comprise monitoring the acceleration to detect an impact, determining the orientation angle of the fall detection device to detect an unnatural orientation of the fall detection device, confirming a change in altitude of the fall detection device based on the measurements of the altimeter, and triggering an alarm.
  • An unnatural orientation of the fall detection device may correspond to a posture of the user that may not typically be assumed when standing or walking. In other words, a position that may be assumed following a fall.
  • the method may further comprise determining the amount of movement of the fall detection device to detect motionlessness. That is, the movement of the user may be checked, for example within a time interval. If the movement stays below a pre-defined threshold, e.g. the average of the movement within a predefined interval stays below a threshold, the user may be characterized as motionless. It will be understood that depending on the threshold the user may not literally be motionless but the overall movement may be smaller than a threshold. This may for example further indicate a fall from which the user cannot recover independently.
  • a pre-defined threshold e.g. the average of the movement within a predefined interval stays below a threshold
  • the method may further comprise comparing the sensor data of a potential fall event to sensor data of known activity patterns and determining if the sensor data corresponds to a known activity pattern. This may be advantageous for avoiding false alarms in case of known activities which may produce sensor readings that could indicate a fall such taking an elevator to go down. For example, by comparing a time series of at least a subset of the sensor data to the sensor data corresponding to known activities the number of false alarms may be reduced.
  • the step of detecting an impact may comprise comparing the linear acceleration to a pre-set threshold, wherein a value above said threshold detects an impact.
  • the frequency at which the acceleration is monitored may be in a range of 1 Hz to 500 Hz, preferably 1 Hz to 100 Hz, such as 50 Hz.
  • the step of detecting an unnatural position of the fall detection device may comprise determining the orientation angle of the fall detection device for the time interval I1, and determining if the orientation angle is above a pre-set threshold for at least a fixed fraction F1 of the time interval to detect an unnatural position of the fall detection device.
  • the zero angle may be associated with the most common position of the device for a person that is standing or walking and large deviations for a prolonged time (e.g. multiple seconds) may indicate an unnatural position, i.e. a position that may correspond to a fall.
  • the step of confirming a change in altitude can comprise comparing the relative change in the average altitude determined in an interval 12 before and in an interval 13 after the impact to a threshold to determine if the altitude of the fall detection device has changed sufficiently to indicate a fall of the user.
  • the intervals 12 and 13 may each comprise a length in the range of 1 s to 15 s, preferably 3 s to 10 s such as 5 s. That is, a relative change of altitude before and after the impact of a potential fall may be determined. This may be advantageous as a fall typically results in a change of altitude particularly for the upper body parts of the user and thus the change of altitude may again be indicative of a fall of the user.
  • the step of detecting motionlessness may comprise determining the amount of movement during the time interval I1, and determining if the amount of movement is below a pre-set threshold to detect motionlessness. Additionally, determining the amount of movement may comprise at least one of determining acceleration and determining changes in orientation during the time interval I1.
  • the collected data on HR and/or oxygen saturation may be used for determining the status of the device and as part of the sensor data for the fall detection algorithm.
  • the sensor data may be used for both, determining if the device is worn and as indication of potential fall events.
  • the step of collecting sensor data may comprise detecting ambient noises and sounds and providing the corresponding sound data, i.e. data on acoustic signals.
  • the method may further comprise analysing sound data from the microphone to identify sounds and noises associated with a fall event. This may be advantageous as typical sound patterns of a fall may be identified, e.g. through comparison. This may for example include the sound of impacts of a body on certain surfaces and/or moaning or screaming of a user in case of injuries and/or shock.
  • the method may further comprise determining the respiratory rate based on the noises and sounds detected by the microphone.
  • the respiratory rate may be determined through sound data provided by the microphone. This may for example indicate the severity of a fall or provide information on the current heath status of a user.
  • the collected data may comprise respiratory rate data.
  • the method may comprise optimizing the power consumption of the device through at least one or a plurality of optimizing the sampling frequency for each sensor to reduce power consumption while maintaining a high precision of the fall detection, adjusting the brightness of the screen automatically depending on ambient conditions, adjusting the design of the user interface depending on current usage, switching the screen on and off depending on position of the device, optimizing the sampling frequency of the HR sensor or pulse oximeter according to the physical activity of the user, optimizing the sampling frequency of the movement sensor(s) according to the HR or pulse oximeter sensor data, and optimize frequency at which components such as communication unit or processing unit are woken up.
  • the position sensor may be switched off or send into a power saving mode if the user is within a known wireless network. Additionally or alternatively, the position may only be updated, i.e. the position sensor may be woken up, if the user is moving based on the sensor data from the at least one movement sensor.
  • the frequency at which the position is determined may depend on the latest position. For example, the position may be determined with a low frequency if the device is close to the home of a user and high if the device is far away from the home of a user.
  • the method may further comprise recharging the battery of the fall detection device via a cable connected to the connector and/or wirelessly recharging the battery of the fall detection device.
  • the method may further comprise connecting to an external handheld device. Further, the method may comprise utilizing the fall detection device as a user interface for the handheld device. The method may further comprise displaying content of the external handheld device.
  • the present invention relates to the use of the device, system or method as described above for the detection of falls of a user.
  • the use may further comprises triggering an alarm in case a fall of the user is detected.
  • the present invention may provide a device, system and method for fall detection which may provide an improved accuracy of fall detection, i.e. it may reduce the number of false positive alarms and/or false negatives. This may be advantageous as it may improve the safety of the user and for example enable the user to live a more independent life.
  • the fall detection device 100 also simply referred to as device 100, may very generally comprise a plurality of sensors 110,120,130, a user interface 140, a processing unit 150, a communication unit 160, a memory 170 and a battery 180.
  • the at least one status sensor 110 may be configured to provide data on the status of the device, that is if the device is worn or not. This information may be particularly important if the device is falling down without being worn, which could lead to false alarms (FP). It is a goal of the invention to reduce the occurrence of false alarms and thus the status sensor 110 is important for the overall functionality.
  • worn may be understood as worn on the body. That is, it may refer to a device 100 that is worn tightly attached to some part of the body, such as on the wrist or clipped to the waist, however it may also refer to a device 100 that is worn more loosely, such as in a pocket, a backpack, on a necklace or in a hand.
  • the status sensor 110 may have further functionality, i.e. in some instances it may provide more data than just the status of the device.
  • the status sensor 110 may primarily be a sensor for vital signs.
  • the status of the device may be determined through the presence or absence of a vital sign.
  • a HR sensor only provides HR data if the device is worn. This may be advantageous to a common proximity sensor, which may provide false readings if the sensor is blocked (accidentally or purposefully).
  • At least one movement sensor 120 may provide data on the movement of the device and subsequently on the movement of the user in case the device is worn.
  • the one or more movement sensor is at least one of an accelerometer 121, a gyroscope and a magnetometer. These sensors may be used to monitor movements and/or the orientation of the device 100.
  • the at least one ambient sensor 130 may provide data on the ambient conditions of the device.
  • the device 100 comprises at least one altimeter 131 configured to measure the altitude of the device 100.
  • the altimeter 131 comprises a barometric pressure sensor configured to measure changes in the ambient barometric pressure. Based on a change in the barometric pressure a change in altitude may be estimated.
  • the altimeter may also comprise a temperature sensor configured to sense the ambient temperature which may be considered when estimating the altitude based on the measured pressure.
  • the device is operated through a processing unit 150 which typically comprises a central processing unit (CPU) or at least one circuit, such as an application specific integrated circuit (ASIC).
  • a processing unit 150 typically comprises a central processing unit (CPU) or at least one circuit, such as an application specific integrated circuit (ASIC).
  • CPU central processing unit
  • ASIC application specific integrated circuit
  • the processing unit 150 may acquire and store data from the sensors and run algorithms for processing and analysing the sensor data to identify a fall event and subsequently take corresponding measures according to the situation, e.g. send an alarm to a call centre or family members.
  • the frequency of acquiring sensor data can be specific to each sensor and happen at pre-defined intervals or conditional on specific events, such as certain values measured by other sensors.
  • the processing unit 150 may run an algorithm to estimate the level of severity of a fall event. This may enable to choose the actions to take based on the likely severity of the detected fall. For example, a light fall may only require a call centre or family member to call and check if everything is ok, whereas a severe fall may even require dispatching of emergency personnel.
  • the communication unit 160 of the device 100 may serve to send and receive instructions, sensor data, operational data or the like, e.g. it may communicate with external sensors, servers and call centres. Most importantly, the processing unit 150 may send an alarm via the communication unit 160 in case a fall of the device user is detected. Therefore, the communication unit 160 may provide means to establish wireless connections to external sensors, severs, phones and other devices relevant to the operation, for example via a cellular network, WLAN or WPAN (e.g. Bluetooth® or ANT+).
  • a cellular network e.g. Bluetooth® or ANT+
  • Part of the memory 170 may store sensor data for further processing and analysis.
  • this part of the memory is configured as a ring memory. That is, the memory has a finite size and is filled successively with sensor data until the memory is full. Subsequently, the oldest data point is replaced with the latest data point, therefore keeping the x latest data points, where x is the maximum of data points that can be stored in the memory.
  • Another part of the memory 170 may store machine-readable program code, that, when executed on the processing unit 150, causes the processing unit 150 to execute the tasks and steps required to operate the fall detection device 100. That is, the memory may for example store machine-readable program code corresponding to a fall detection algorithm that identifies a fall detection event based on the sensor data when run by the processing unit 150.
  • the battery 180 is designed to power the device 100 and is either removable or rechargeable (or both). In other words, in some embodiments the battery can be removed from the device whereas in other embodiments it is not designed to be removed by the user. In the latter case, the battery is rechargeable via a cable or wirelessly, while in the first case it may not be rechargeable.
  • the power consumption of the device 100 may be managed by the processing unit 150 in order to extend the battery lifetime while ensuring reliable operation of the device 100, e.g. by sending individual parts into a power saving mode or powering down components temporarily for intervals in which they are not required.
  • the power consumption of the device 100 may be optimized by the processing unit 150 in order to reduce the energy consumption while ensuring save operation of the device 100.
  • the device may utilise a HR sensor 112 as status sensor 110, i.e. the device checks if it is worn by checking if a valid HR signal is measured.
  • a HR sensor 112 may either be an electrocardiography (ECG) sensor or, preferably, a photoplethysmography (PPG) sensor.
  • ECG electrocardiography
  • PPG photoplethysmography
  • the measurement of a pulse and/or HR signal indicates that the device 100 is worn. This may be advantageous as such a vital signal is hard to synthetically create and thus provides a good indicator of the device status.
  • the device 100 may be a wristwatch with an optical (PPG) HR sensor that will measure the HR of the user once the watch is placed on the wrist.
  • PPG optical
  • an optical (PPG) HR sensor may be able to also measure the oxygen saturation in the blood.
  • the sensor data of the status sensor 110 may also be used as data for the fall detection algorithm.
  • the HR of the user may also provide an indication if a user has fallen or not. That is, the status sensor data is not necessarily exclusive for the determination of the device status.
  • the fall detection device 100 may also comprise a proximity sensor as a status sensor 110. That is, the status of the device may be determined by a means of a proximity sensor. Further, the status may also be determined based on a combination of data from the proximity sensor and the heart rate sensor 121.
  • the movement sensor 120 in the depicted embodiment is an accelerometer 121, which may provide data on the static and dynamic acceleration of the device and thus enable to extract information of the device orientation relative to the surface of the earth.
  • the acceleration data may be filtered by means of a low-pass filter, e.g. a Butterworth filter, in order to extract the gravity component, which is basically static. Therefore, the sensor 121 may provide data on the dynamic (linear) acceleration corresponding to the movement of the device 100 and on the orientation relative to the gravitational field (i.e. the earth surface) by relating the dynamic acceleration data to the (static) gravity component.
  • a low-pass filter e.g. a Butterworth filter
  • the sensor 121 may provide data on the dynamic (linear) acceleration corresponding to the movement of the device 100 and on the orientation relative to the gravitational field (i.e. the earth surface) by relating the dynamic acceleration data to the (static) gravity component.
  • Such an accelerometer may for example be based on a microelectromechanical system (MEMS).
  • MEMS microelectromechanical system
  • the device 100 may comprise three ambient sensors 130.
  • the altimeter 131 also referred to as barometer 131, may provide data on the ambient barometric pressure. Through comparison of the estimated altitude at different times (or time intervals) a relative change in altitude may be determined. In other words, since the barometric pressure also depends on the altitude a relative change in height of the device can be estimated from the altimeter data.
  • the data of the altimeter may also allow to estimate the absolute altitude of the device, for this, context data such as current weather may be used to improve the accuracy.
  • a light sensor 132 may measure the illuminance in the surrounding of the device 100, and thus provide data for adjusting the brightness of a screen 141. This way, the brightness can for example be chosen such that the power consumption is reduced while still ensuring readability for the user.
  • the ambient lighting conditions may also serve to provide context data for the fall detection algorithm since darker conditions may increase the risk of falling if a user is moving.
  • a position sensor 133 may provide data on the global position of the device based on a global navigation satellite system such as GPS or Gallileo. This may be important in case of an alarm, as it enables the device 100 to provide data on the position of the user to the emergency contacts or services. This data may also be used to improve the accuracy of determining the absolute altitude.
  • a global navigation satellite system such as GPS or Gallileo.
  • the position detection may be supported by the cellular network and/or WLAN, as well as other signals that may enable localisation.
  • cellular networks may enable for mobile phone tracking, e.g. through localization based on the global system for mobile communications (GSM).
  • GSM global system for mobile communications
  • IP localization or a Wi-Fi positioning system may provide means to localise the fall detection device.
  • Such techniques may be combined with the position sensor to allow for a localization indoors and outdoors and additionally may enable reduction of the power consumption of the device.
  • the user interface 140 may comprise a screen 141 which may for example show notifications for the user, information on the device status and charging status of the battery, settings of the device, current time, etc.
  • the screen 141 may be a touch screen, allowing the user to interact with the device, for example to change device settings, abort or trigger an alarm, edit personal information of the user, etc.
  • the brightness of the screen 141 may be adjustable to optimise power consumption and readability depending on ambient conditions and operating condition, e.g. in case of an alarm the screen brightness may be maximised to ensure readability.
  • the user interface 140 may comprise a physical button 142, allowing the user to manually trigger an alarm in case of a fall, or potentially another emergency situation, if the device did not automatically detect the event. That is, the user can manually trigger an alarm by actuating the button on the device.
  • the button may also enable the user to abort an alarm during a de-escalation phase in case it has been triggered. Such a de-escalation phase my generally follow the triggering of an alarm to inform the user and provide a possibility to abort the alarm in case it has been a false alarm (FP).
  • FP false alarm
  • the user interface may comprise a virtual button instead of or in addition to the physical button 142.
  • a virtual button may for example be an area of the touch screen 141, a pressure sensitive area on the device, or a motion sensor configured for gesture control.
  • a virtual button can for example be realised by registering a tapping on the device with the accelerometer 121 or repeated covering of the light sensor 132.
  • a virtual button may provide the same functionality as a physical button 142 when actuated.
  • a button may also provide functionalities other than triggering or aborting an alarm, e.g. a button may be used for changing settings of the device or for reacting to a message shown on the screen 141.
  • the user interface 140 may further comprises a loudspeaker 143.
  • the speaker may for example generate a beeping sound or an alarm sound during the de-escalation phase following an alarm.
  • the device 100 may also comprises a microphone 144 which is part of the user interface 140, e.g. for voice commands. However, it may also function as a sensor. For example, the microphone 144 can detect sounds and noises in the surrounding of the device 100, that may be associated with a fall through sound recognition patterns. Further, the microphone 144 may provide data on the breathing of the user by monitoring the corresponding sounds.
  • a microphone 144 which is part of the user interface 140, e.g. for voice commands. However, it may also function as a sensor.
  • the microphone 144 can detect sounds and noises in the surrounding of the device 100, that may be associated with a fall through sound recognition patterns. Further, the microphone 144 may provide data on the breathing of the user by monitoring the corresponding sounds.
  • microphone 144 and loudspeaker 143 may further allow the user to have a phone call with the corresponding emergency contact or the emergency services.
  • the device 100 may also comprise a haptic feedback unit 145 which may comprise at least one vibrational motor.
  • a haptic feedback can be provided, e.g. during the de-escalation phase or in case of a notification.
  • the device comprises a processing unit 150, a communication unit 160, a memory 170 and a battery 180 as described above.
  • the device status may be checked in regular intervals (not shown in Fig 3 ). That is, the data of the at least one status sensor 110 may regularly be analysed to confirm that the device 100 is worn. In the case of the HR sensor 112 this means, that the presence of a valid HR signal is regularly checked to validate that the device 100 is worn, whereas for a proximity sensor it may be checked that an object is in close proximity to the proximity sensor and thus the device 100.
  • checking the device status may be part of the fall detection algorithm, that is it may be one of the steps of the fall detection algorithm.
  • the fall detection algorithm depicted in Fig. 3 may then monitor the data generated by the accelerometer 121 to identify any impact (step 210), wherein the acceleration data may be received either directly from the sensor or via the memory. As discussed earlier, the acceleration data may be pre-processed to be separated in to the gravity component and the linear (dynamic) acceleration.
  • a fall consists of a phase of reduced acceleration due to the (approximately) free fall and then a moment with a high spike in the acceleration due to an impact, e.g. on the floor.
  • the algorithm may compare the acceleration to a threshold value set to identify such an impact.
  • the acceleration data may be preferably collected and analysed with a frequency in the range of 0.1 Hz to 1kHz, preferably in the range of 1Hz to 500 Hz, more preferably in the range of 1 Hz to 100 Hz, such as 50 Hz. That is in the case of 100 Hz the algorithm checks for an impact 100 times per second.
  • the sound data may be analysed (step 220). That is, sounds and noises recorded by the microphone 144 may be analysed to determine if a fall might have happened. That is, for example recorded sound patterns around the time of the impact may be analysed to recognize sound patterns which are associated with a fall, e.g. sound of an impact on a floor or a scream of a user. This may further increase the accuracy of the fall detection algorithm.
  • the biomechanical posture of the user of the fall detection device 100 may be checked (230).
  • the orientation angle of the device may be checked to detect an unnatural orientation of the fall detection device.
  • the orientation may be estimated by extracting the gravitational vector from the acceleration data. This may be done by low-pass filtering the data since the gravitational component can be approximated to be static. By evaluating the direction of the gravitational acceleration, the angle of the device relative to the earth surface may be estimated.
  • the fall detection may further comprise a gyroscope to provide additional orientation data and thus improve the precision at which the orientation angle of the device may be determined.
  • the orientation angle may be determined only based on the gyroscope data or, preferably, based on the gyroscope and the accelerometer data.
  • the orientation angle of the device may be indicative of the posture of the user.
  • the fall detection device 100 is a wrist watch, it may indicate if the arm of the user is within the biomechanical constraints of the human musculoskeletal system.
  • Certain postures may be associated with a high likelihood of a preceding fall (these postures may be referred to as unnatural position) and thus the algorithm may proceed to the next step, alternatively the algorithm may return to step 210 if for example the identified posture indicates that the user has recover from a fall.
  • the movement of the user may be checked (step 240).
  • the movement of the device within the interval may be analysed and in case the overall movement of the device 100 (and thus the user) stays below a pre-defined threshold the algorithm proceeds to the next step. Only if there is sufficient movement of the device registered, the algorithm goes back to 210. If the user is moving but still requires help, the alarm may be triggered manually.
  • step 250 the algorithm evaluates the data from the altimeter 131, e.g. the barometric pressure, to estimate the altitude in an interval before and after the fall detection event, respectively.
  • the changes in altitude may be indicative of a fall of the device (and the user).
  • the algorithm may simply compare the average altitude in the two intervals to estimate a relative change in altitude, or alternatively the algorithm may for example check if changes in the altitude signal within these two intervals match a specific signal pattern. If changes in the altitude are considered to be indicative of a fall, the algorithm may move to the next step. If the data of the altimeter indicates no changes in altitude typical of a fall, e.g. the changes do not match this pattern, the algorithm may for example go back to step 210. For estimating the altitude also other data may be considered, for example data on the ambient temperature.
  • the leg length is typically above 60 cm, thus if the fall detection device is worn at the upper body or the wrist a change in altitude of at least 50 cm may be expected.
  • the threshold may be personalized according to the body proportions and the place where the fall detection device is worn.
  • the step of determining the change in altitude may be advantageous for example to prevent alarms in case a user is hitting a table with his hand, e.g. during playing cards. This may lead to a detection of an impact and an orientation angle above the threshold but does of course not correspond to a fall event.
  • checking the altitude provides means to reduce the occurrence of FP, improving the accuracy of the fall detection device.
  • the algorithm may compare the activity pattern to known activity patterns to avoid false alarms (step 260). That is, based on the collected sensor data, the algorithm may determine if the sensor data around the point of the identified impact or potential fall event can be can be associated to a known activity pattern, e.g. stored in a database of known activity patterns. That is, the sensor data may be compared to the sensor data of known activity patterns to rule out that an alarm is triggered due to a known activity which may lead to sensor readings that mimic a fall event.
  • taking an elevator may result in sensor readings that may cause the fall detection algorithm to detect an impact, alongside with a change of altitude and potentially reduced movement such that it may lead to the result that a fall may have happened.
  • the sensor data By comparing the sensor data to known activity patterns it may be identified that the user was taking an elevator and thus a false alarm may be prevented.
  • the fall detection may trigger an alarm if all the preceding steps indicate that a fall has happened (step 270).
  • the fall detection algorithm may for example also comprise a step of estimating the severity of a fall based on the measured sensor data.
  • the severity may be based on the amplitude of the impact and/or the amount by which a threshold is exceeded.
  • the fall detection algorithm may return to its first step upon finding that in one step the data does not correspond to a fall event, e.g. if there was no sufficient change in altitude.
  • a further step may be executed to confirm that no fall has happened.
  • only one of two steps may be required to indicate that a fall has happened for the algorithm to continue.
  • it is enough if either a sufficient change of altitude was measured (step 250) or the movement was below a pre-defined threshold (260).
  • both of the steps are required to indicate that a fall has happened.
  • the fall detection device 100 may be part of a fall detection system 200, also referred to as system 200.
  • a system 200 may further comprise at least one or a plurality of external sensors 310 which may provide additional data for the fall detection device. These data may provide further sensor data for the fall algorithm and/or provide medical background data, e.g. in case of a fall event.
  • the fall detection device 100 may communicate and exchange data with the external sensors via a wired connection or, preferably, a wireless connection, such as a wireless personal area network, e.g. Bluetooth® or ANT+ or WLAN.
  • a wireless connection such as a wireless personal area network, e.g. Bluetooth® or ANT+ or WLAN.
  • the system 200 may comprise a professional service 320, which may for example be a professional service provider or call centre.
  • the fall detection device 100 may be configured to send an alarm message to and/or establish a phone call with the professional service 320 in case an alarm is triggered and not aborted.
  • the fall detection device 100 may share data with the professional service 320, such as medical data, summary of activity of the user or the like. This way, the professional service 320 may also be informed about the general health status of the user and may be enabled to provide preventive measures and assistance to the user and/or his family and friends.
  • the professional service 320 may also be informed about the general health status of the user and may be enabled to provide preventive measures and assistance to the user and/or his family and friends.
  • the system 200 may comprise at least one emergency contact 330, such as a family member or a friend.
  • the one or more emergency contacts may be contacted by the emergency device 100 in case of an alarm that is triggered and not aborted. That is the fall detection device may send an alarm message and/or establish a phone call between the user and the emergency contact 330.
  • An alarm message may for example contain information about the estimated severity of a fall, timing information, user ID, medical background information, sensor data such as position and vital signs. This may be advantageous as it may enable the professional service 320 or the emergency contact 330 to get a better judgement of the situation and enable them to take the appropriate measures.
  • an alarm message may be sent or a phone call established in case an alarm has been aborted.
  • the fall detection system 200 may further comprise a server 340 which may be configured to communicate and exchange data with the fall detection device 100.
  • the server may store data received from the fall detection device 100, e.g. for training or personalization of the fall detection algorithm.
  • the fall detection device 100 may send an alarm message to the sever 340 in case an alarm has been triggered and not aborted. This may be either instead or in addition to an alarm message or phone call to an professional service 320 and/or emergency contact 330.
  • the server 340 may also store data regarding past alarms that have been triggered either manually or automatically alongside a part (or all) of the corresponding sensor data. These data may represent datasets corresponding to TP (automatically triggered) or FN (manually triggered), which may serve to train and improve and/or personalize the fall detection algorithm.
  • the server 340 may also store information on aborted alarms together with at least a subset of the corresponding sensor data. This data would correspond to FPs which may also be used for training, improving and/or personalizing the fall detection algorithm.
  • the stored data may be supplemented by information from the user, professional service 320 and/or emergency contact 330 to provide more detailed feedback on the fall event.
  • the server may in some embodiments also store sensor data that does not correspond to a triggering or aborting of an alarm, i.e. data on TNs, which could for example be sensor data corresponding to a specific activity or a standard routine or also a stumble of the user. This data may also be used for training, improving and/or personalizing the fall detection algorithm.
  • the data stored may also comprise sensor data on the ambient conditions, which may also be used as an input to the fall detection algorithm.
  • Part of the above-mentioned data may also be helpful for identifying preventative measures.
  • the data may reveal potentially risky situations for the user which may be avoided through certain measures, such as adjusting medication, changing furniture position, etc.
  • the server 340 may also communicate and exchange data with one, or a plurality of, external sensor(s) 310, e.g. to collect their data and store it and/or send it to the fall detection device 100.
  • the server 340 may be a remote server, more precisely it may be a dedicated server, a cloud-based server or for example a combination of a dedicated server and cloud-based storage.
  • a de-escalation step 410 may be entered during which the user may be able to still abort the alarm. This is particularly useful in cases of FP or if the user was able to recover from the fall and does not require further assistance, i.e. the severity was low. This step may also be referred to as de-escalation phase 410.
  • the de-escalation phase 410 will last for a pre-defined time, e.g. 5 s or 10 s.
  • the length of the de-escalation phase 410 may be 0 s, that is the de-escalation step 410 may be skipped.
  • the length of the time interval may be defined with respect to the estimated severity of a fall. That is, there may be more time for the user in case of a less severe fall event in comparison to a sever fall event where the de-escalation step 410 may be very short or, in some instances, skipped.
  • a countdown may be shown on the screen 141, indicating the time remaining until the alarm message is sent. Further, the countdown may be accompanied by a sound played via the loudspeaker 143, e.g. there may be a "beep" every second of the countdown.
  • the haptic feedback unit 145 may also indicate the presence of a countdown and thus the possibility to cancel the alarm, e.g. the device may vibrate during the countdown.
  • the user may be enabled to abort the alarm in different ways.
  • the user may use the button 142 to cancel an alarm that hast already been triggered. That is, the button triggers an alarm in case no alarm has been triggered yet and aborts an alarm in case the device is in the de-escalation phase 410.
  • the device may have two buttons, one button 142 to trigger an alarm and another button to cancel an alarm during the de-escalation phase 410.
  • the user may cancel an alarm by tapping on the touch screen 141.
  • the user may be required to tap the screen three times in order to reduce the likelihood of accidently cancelling an alarm.
  • a voice command may be a predefined command, e.g. "stop”, "cancel alarm”, or similar phrases.
  • the escalation step 420 may include sending an alarm message, e.g. an SMS, to at least one of a professional service 320 and an emergency contact 330.
  • the message may include information about the event, e.g. estimated severity of the fall, user ID, medical background of the user, location of the user, e.g. GPS coordinates of the device location, and/or summary of the vital signs measured by some of the sensors of the device 100.
  • the user may specify a list of contacts that receive an alarm message upon entering the escalation step 420.
  • the device 100 may trigger a phone call to an emergency service 320 or an emergency contact 330 enabling the user to speak to the emergency contact or service using the microphone 144 and the loudspeaker 143 of the device 100.
  • the user may specify a list of emergency contacts 330.
  • the device 100 may then attempt to establish a phone call with the first emergency contact 330 and only call the second emergency contact 330 in case the first cannot be reached and so forth. This may increase chances of reaching at least one emergency contact 330.
  • the de-escalation phase 410 may be skipped, however in order to avoid FP due to accidentally triggering the alarm, the de-escalation phase 410 may still be entered in case of a manually triggered alarm.
  • the fall algorithm may be based on statistical classification methods, such as machine learning methods.
  • a first step for generating a model may be the collection of data that is accurate enough to generate a proper training file.
  • a data collection may involve exemplary sensor data for fall events in different situations and surroundings, e.g. fall from a standing position to the front, back or side, fall onto a piece of furniture, fall during a physical activity etc., furthermore the data collection may comprise exemplary sensor data on near fall events, e.g. a person stumbling but not falling, on physical activities, e.g. a person running or jumping or on activities normally performed when at home, e.g. sitting down on a bed or sofa, cleaning or cutting vegetables and fruits.
  • Such a data collection may enable identifying and training of an appropriate classification algorithm that is able to distinguish between fall and non-fall events with a high success rate, i.e. limited number of FP and TN.
  • the features required for the classification may be assessed and refined.
  • a final model may be generated using the selected features and the classification algorithm.
  • This model may then be implemented into the real time application, e.g. the fall detection device 100, with the capability to update the model. This way, the model may be adaptable for different users and/or groups of users.
  • the processing unit 150 may receive and analyses the sensor data to extract corresponding features.
  • Such features may be statistical quantities of a data set, such as the mean or standard deviation, or other measurable or characterising properties, e.g. maximum/minimum value, a certain ratio, etc. These features may then form a feature set that may be characteristic for a certain instance in time.
  • a feature set includes at least one feature of a status sensor 110, a movement sensor 120 and an ambient sensor 130, respectively.
  • the feature set may be provided to the fall detection algorithm which may be based on a predetermined model that may classify the data into fall and non-fall events. It will be understood, that the fall detection algorithm comprises an implementation of the model.
  • sensor data may be stored to later serve as training data for improving the classification algorithm and/or the model that is based on said classification algorithm.
  • data may particularly be data of FP (i.e. when the alarm is aborted by the user), FN (i.e. when the alarm is triggered by the user) and TP (i.e. when an automatically triggered alarm is not aborted by the user).
  • TN data may be saved, i.e. for example data that corresponds to a certain physical activity.
  • the training data may be improved through feedback of the user with reference to certain fall and non-fall events. For example, the user may be asked to confirm a fall and/or rate the severity thereof.
  • the fall detection device 100 may further comprise means for realizing contact tracing and/or proximity tracing. That is, very generally during an epidemic and/or pandemic, e.g. with a contagious virus, such as an influenza or corona virus, it may be desirable to be able to determine who was in close proximity of an infected person during a period where the person may already have been contagious. That is, such viruses may for example spread via aerosols in the breath of a person, which may typically be particularly contagious over a distance of 1.5 to 2 m.
  • contract tracing may be conducted via interviews, wherein an infected person would be asked to recall the contact persons and visited places during the potentially contagious period, e.g. 2 weeks.
  • Bluetooth® and specifically Bluetooth Low Energy BLE
  • BLE Bluetooth Low Energy
  • each device may periodically share a respective identifier, which will be received by nearby devices and can be stored to record potential proximity to another person.
  • the principal would be similar (or the same) as for Bluetooth beacons, which may typically also rely on broadcasting an ID via Bluetooth Low Energy.
  • the storage of such an ID may for example depend on the time two devices were in close proximity and the estimated distance between the two devices.
  • the distance to other device may for example be estimated via the signal strength of the received Bluetooth signal in comparison to the signal strength at which it was send out, which may for example also be shared as information).
  • Such a method may have the advantage, that only proximity to other persons may be tracked and no location, such that it may be impossible, or at least hard, to deduct a movement pattern of a person.
  • the fall detection device which may for example be a wristwatch, such as a smartwatch, may further be configured for proximity tracing. That is, the fall detection device may be configured to implement proximity tracing, in particular privacy-preserving proximity tracing, such as PEPP-PT or DP3T.
  • the communication unit 160 may be configured to provide and receive a Bluetooth Low Energy signal, particularly to broadcast and receive respective identifiers, such as an Ephemeral Identifier.
  • said identifiers may be encrypted.
  • the identifiers may for example be based on a secret seed which may be generated when the respective feature is initially activated on the fall detection device, e.g. when a respective program or application is installed.
  • Each identifier may typically only be utilized for a pre-set time interval, e.g. 15 min, 20 min or 60 min 45 min or 60 min in order to comply with privacy obligations. That is, the fall detection device 100 may generate a number of different identifiers, e.g. based on a secret seed and utilizing a pseudo random function as well as a stream cipher.
  • Received identifiers which are broadcasted by nearby devices may for example be stored in the local memory 170 alongside an indication of the date and/or time it was received.
  • Storage of an identification may depend on the estimated distance of the corresponding device, e.g. from the signal strength, and the time the corresponding device was in close proximity. Furthermore, the stored identifiers may be automatically deleted after a set period of time, which may for example correspond to the time period a person is considered to be contagious, e.g. 14 days or 21 days.
  • the fall detection device may notify the user that there may be an increased risk for an infection and for example inform the user of further steps.
  • the fall detection device may further be configured to also notify an emergency contact 330 and/or an emergency service 320.
  • the fall detection device may be utilized to inform (anonymously or at least pseudo anonymously) other devices (and their users) that have been in close proximity during the relevant contagious period according to the rules and implementation of the utilized protocol, e.g. DP3T or PEPP-PT.
  • the fall detection device may generally be designed such that it can be worn without significantly restricting the user, which may increase the likelihood of it being worn and decrease the chances for forgetting it, since it is typically (unlike a smart phone) attached to the body, e.g. as a wristwatch.
  • particularly elderly people are often at risk during an epidemic or pandemic may not own a smartphone.
  • they may already utilise a fall detection device, such that the additional functionality of proximity/contact tracing may be implemented without affecting the routine of these people.
  • the willingness to carry a fall detection device which may be small and easy to handle, e.g. as a wrist watch, may be higher than getting a smartphone only for being able to have access to proximity tracing.
  • step (X) preceding step (Z) encompasses the situation that step (X) is performed directly before step (Z), but also the situation that (X) is performed before one or more steps (Y1), ..., followed by step (Z).
  • step (Z) encompasses the situation that step (X) is performed directly before step (Z), but also the situation that (X) is performed before one or more steps (Y1), ..., followed by step (Z).

Landscapes

  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • Emergency Management (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Gerontology & Geriatric Medicine (AREA)
  • Business, Economics & Management (AREA)
  • Social Psychology (AREA)
  • Psychiatry (AREA)
  • Emergency Alarm Devices (AREA)
  • Psychology (AREA)
  • Biophysics (AREA)
  • Cardiology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Physical Education & Sports Medicine (AREA)
  • Physiology (AREA)
  • Pulmonology (AREA)
  • Alarm Systems (AREA)
  • Life Sciences & Earth Sciences (AREA)
EP20188159.6A 2019-07-29 2020-07-28 Dispositif, système et procédé de détection de chute Withdrawn EP3796282A3 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP19188875 2019-07-29

Publications (2)

Publication Number Publication Date
EP3796282A2 true EP3796282A2 (fr) 2021-03-24
EP3796282A3 EP3796282A3 (fr) 2021-05-26

Family

ID=67539179

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20188159.6A Withdrawn EP3796282A3 (fr) 2019-07-29 2020-07-28 Dispositif, système et procédé de détection de chute

Country Status (1)

Country Link
EP (1) EP3796282A3 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023098278A1 (fr) * 2021-12-03 2023-06-08 International Business Machines Corporation Initiation d'une communication sur un dispositif mobile en réponse à un événement

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8179268B2 (en) * 2008-03-10 2012-05-15 Ramot At Tel-Aviv University Ltd. System for automatic fall detection for elderly people
US9049998B2 (en) * 2012-06-22 2015-06-09 Fitbit, Inc. Biometric monitoring device with heart rate measurement activated by a single user-gesture
US10624559B2 (en) * 2017-02-13 2020-04-21 Starkey Laboratories, Inc. Fall prediction system and method of using the same
WO2019063576A1 (fr) * 2017-09-29 2019-04-04 Koninklijke Philips N.V. Bracelet détecteur de chute sur la base d'une direction du bras

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023098278A1 (fr) * 2021-12-03 2023-06-08 International Business Machines Corporation Initiation d'une communication sur un dispositif mobile en réponse à un événement
US12058587B2 (en) 2021-12-03 2024-08-06 International Business Machines Corporation Initiating communication on mobile device responsive to event

Also Published As

Publication number Publication date
EP3796282A3 (fr) 2021-05-26

Similar Documents

Publication Publication Date Title
US9959732B2 (en) Method and system for fall detection
US10485452B2 (en) Fall detection systems and methods
WO2017049958A1 (fr) Appareil de détection de paralysie et d'alarme et son procédé de traitement
US11047706B2 (en) Pedometer with accelerometer and foot motion distinguishing method
EP3188569B1 (fr) Procédé destiné à détecter le glissement d'un dispositif vestimentaire et dispositif vestimentaire
RU2584459C2 (ru) Жестовое управление для отслеживания показателей жизнедеятельности
KR101797854B1 (ko) 스마트 밴드를 이용하여 낙상을 판단하는 방법 및 시스템
RU2685815C1 (ru) Способ реагирования на обнаружение падения и устройство для его реализации
US10332378B2 (en) Determining user risk
KR101638408B1 (ko) 낙상 감지를 위한 웨어러블 모션 센서 장치, 이를 이용한 낙상 감지 시스템 및 낙상 감지 방법
US20180008191A1 (en) Pain management wearable device
JP2002251681A (ja) 動作検知装置、動作検知システム、異常動作通知システム、ゲームシステム、所定動作の通知方法およびセンタ装置
WO2011055255A1 (fr) Procédé et système pour annuler une alarme de chute
WO2019097248A1 (fr) Améliorations apportées ou se rapportant à des détecteurs de chute et détection de chute
KR101830003B1 (ko) Ｕ―헬스 케어 기반의 위험 상황 알림 시스템, 그리고 이를 이용한 위험 식별 방법
CN205665839U (zh) 可穿戴智能跌倒检测警报通知系统
CN103714249A (zh) 一种用户行为安全的监测方法及设备
Colon et al. Human fall detection with smartphones
KR101754576B1 (ko) 탈착 디바이스를 이용한 생체 신호 분석 시스템 및 방법
EP3796282A2 (fr) Dispositif, système et procédé de détection de chute
JP4494843B2 (ja) ペット管理システム
KR101270004B1 (ko) 신체활동 측정 시스템, 그 측정방법, 이를 이용한 신체활동 및 응급상황 안내방법
Singh et al. Implementation of safety alert system for elderly people using multi-sensors
US20230389880A1 (en) Non-obtrusive gait monitoring methods and systems for reducing risk of falling
EP3991157B1 (fr) Évaluation de mouvement d'un sujet

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: QOLWARE GMBH

RIC1 Information provided on ipc code assigned before grant

Ipc: G08B 21/04 20060101AFI20210420BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210628

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230621

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20231103