SP3-23 Driver/passenger health assistant in critical conditions
Context of use (aim)
The purpose is to monitor the health status of the elderly driver or passenger(s), using a set of wearable sensors, and to take necessary countermeasures if any anomalous conditions are detected. This is done by means of an in-vehicle system, depending on the following situation:
In case of actual safety risk, the vehicle system calls an external emergency centre (autonomous operation), or
In case of potential safety risk, the vehicle system alerts the driver about the altered health status and suggests him/her to ask for help (semi-autonomous operation) or undertake other actions, depending on the potential risk level. If the driver asks for external help, the emergency centre is contacted.
Health care and emergency support service providers
Telematic service providers
Connected UCs
Personal mobility UC3,Driver/passenger health monitoring on demand (system architecture is analogous)
Priority Level
Essential
Scenario(s)
The user wears some sensors measuring his/her vital signs (e.g.: heart rate, blood pressure, body temperature, etc.). The sensors are connected to a control unit hat collects the data. This unit will be generically called “in-vehicle system”, and it could be the vehicle’s own telematic unit, or the unit + a PDA, etc.
Autonomous operation:
The user has a sudden disease and is in safety risk.
Semi-autonomous operation:
The user is not in safety risk, but one or more of the parameters measuring the health status of the user are out of the safeguard control limits.
System output
Autonomous operation
The system automatically starts an emergency call, contacting a nearby first-aid centre.
Semi-autonomous operation:
The in-vehicle system alerts the user about altered health conditions, suggesting him/her to take countermeasures (e.g. take a break) or ask for assistance (preventive action). The type of suggestion depends on the actual health conditions. If the driver asks for external help, the in-vehicle system contacts the service centre.
Efficiency and reliability of data transfer and communication system (i.e.: transmissions from the vehicle to the emergency centre or service provider and vice-versa).
User friendliness of the peripherals/HMI system.
Health monitoring
Accuracy and reliability of the sensor acquisitions.
Environmental restrictions
Potential problems concerning data transmissions, based upon the GSM/UMTS network (i.e.: lack of coverage within certain areas, for example in tunnels).
Interaction level
Step 1 – there is a problem concerning the user’s health status, related to one or more vital parameters measured by the sensor system/structure.
Step 2 – depending on the (estimated) gravity of the situation, the system decides whether to
autonomously call an emergency centre => step 4
or to
warn the user3 => Step 3
Step 3 – the user receives the warning and decides to undertake the suggested action.
Take autonomous countermeasures
(e.g. stop and take a break )
=> end of the UC
Ask for help
=> step4
Step 4 – a call is started by the system and the user is put in contact with the service centre. Details will be clarified during the project.
Personalisation/ adaptation level
Yes:
static parameters: static user profile (i.e.: name, date of birth, etc.)
semi-dynamic parameters: user’s case history and medical data (i.e.: known pathologies, allergies, etc.)
dynamic parameters: current values of the user’s health parameters acquired by the wearable sensors
For the QoS, we will refer to the recommendations of the Driving Group eCall, concerning:
percentage of the triggered emergency calls that reach the mobile network operator;
percentage of the activated emergency calls that reach the emergency centre (forwarded by the network operator);
latency of intervention.
Another QoS indicator that must be considered is the reliability of sensor data acquisitions.
Potential input needed from other UCs (what input and which UCs?)
Important accessibility attributes (per UG)
The HMI structure, including connected peripherals, must be designed taking into account the elderly user needs.
The health monitoring and alerting/emergency functions must be always available and working.
User’s profile and medical profile must be considered in order not to trigger warnings unnecessarily.
Background info/ reason on selection and on assigning the priority level
Monitoring the health status of elderly drivers/passengers, in order to supply them with efficient emergency services and warning indicators for prevention, is crucial to avoid dangerous situations, especially those in which the driver/passenger illness sums to the road hazard.
References
Driving Group eCall recommendations.
Comments
The approach based on wearable sensors and on data fusion of various sensor inputs, combined with user’s personalized information, is considered the most significant innovation in OASIS.
Figure 85: SP3-23 Driver/passenger health assistant in critical conditions
SP3-24 Emergency call for road accidents
Context of use (aim)
The objective is to start an emergency call automatically or manually whenever a car accident has occurred, providing the rescue centre information on personal and medical data of the elderly driver/passenger(s), as well as vehicle information.
The Use Case is considered successful if at least the Minimum Set of Data (MSD) foreseen in the emergency call standardization is sent.
The device managing the call generation and transmission is an on-board telematic unit, connected to the vehicle CAN and GPS, which also provides information about the localization of the vehicle.
Primary actor
Υoung elderly (ages 55-65)
Elderly (ages 65-75)
Old elderly (ages 75+)
Secondary actor(s)
Public / private Social security service providers and insurance companies
Personal mobility UC1 – Driver/passenger health assistant in critical conditions(emergency intervention/management is similar)
Priority Level
Essential
Scenario(s)
The user is involved in a car accident and needs help. The emergency authorities must be contacted and informed about the event, to organize the rescue.
System output
An emergency call is started automatically by the in-vehicle system or triggered manually by the user, contacting a first aid centre nearby, or, if possible, connected to an eCall service. Detailed medical and customized data about the user are automatically sent to the centre.
Relevant OASIS WP
WP3.4
Services involved
Driver telematic support
Devices & restrictions
11a. User Interaction devices & restrictions
Portable device (tablet PC, mobile phone, tbd); Vehicle Telematic Unit
11b. Sensor devices & restrictions
Vehicular sensors; localization module
Critical success parameters
Services
Success parameters
Driver telematic support
Efficiency and reliability of data transfer and communication system (i.e.: transmissions from the vehicle to the emergency centre or service provider and vice-versa).
Accuracy and reliability of vehicle positioning.
User friendliness of the peripherals/HMI system.
Environmental restrictions
Potential problems concerning data transmissions, based upon the GSM/UMTS network (i.e.: lack of coverage within certain areas, for example in tunnels).
Interaction level
Step 1 – the user is involved in a car crash.
Step 2 – an emergency call, contacting the nearest service centre, is activated:
autonomously by the in-vehicle system (alerted by the sensing module);
or
manually by the user.
Details will be clarified during the project development.
Step 3 – a connection between the user and the service centre is established.
Personalisation/ adaptation level
Yes:
static parameters: static user profile (i.e.: name, date of birth, etc.)
semi-dynamic parameters: user’s case history and medical data (i.e.: known pathologies, allergies, etc.)
dynamic parameters: vehicle data acquired by the sensor module (positioning and other vehicle data, e.g. odometer, rear crash, front crash, airbag sensors)
environmental parameters/context of use: driving
Quality of service indicators
For the QoS, we will refer to the recommendations of the Driving Group eCall, concerning:
percentage of the triggered emergency calls that reach the mobile network operator;
percentage of the activated emergency calls that reach the emergency centre (forwarded by the network operator);
latency of intervention.
Another QoS indicator that must be considered is the reliability of the vehicle positioning module.
Potential input needed from other UCs (what input and which UCs?)
Information on the user’s vital parameters acquired by the body sensor system of Personal mobility UC1 (Driver/passenger health assistant in critical conditions)could be sent together with the data pertaining to the present UC to the emergency centre.
Important accessibility attributes (per UG)
The HMI structure, including connected peripherals, must be user-friendly to elderly drivers/passengers.
Background info/ reason on selection and on assigning the priority level
The necessity and importance of providing an efficient emergency call service for drivers is proved and universally accepted (refer to the eCall initiative development and standardization process, promoted by the European Commission).
In OASIS, the idea is that of providing an ‘improved’ version of the eCall service, taking into particular account the elderly user needs.
References
Driving Group eCall recommendations.
Comments
This Use Case is based on the standard Emergency Call and should therefore be compliant with it. In the basic version the health monitoring sensors do not enter in the Use Case; they may be seen as optional input (mentioned in 17).
Figure 86: SP3-24 Emergency call for road accidents
SP3-25 Driver/passenger health monitoring on demand
Context of use (aim)
The purpose is to give the possibility to the elderly driver or passenger(s) to receive medical assistance at any time during the travel.
The user wears a set of sensors measuring his/her vital signs; then, by means of an in-vehicle telematic device, he/she can make a request for support to the health care centre, which will evaluate the situation, based on these parameters, and give a medical response.
Primary actor
Young elderly (ages 55-65)
Elderly (ages 65-75)
Old elderly (ages 75+)
Secondary actor(s)
Service Centre
Health care and emergency support service providers
Telematic service providers
Connected UCs
- Personal mobility UC1, Driver/passenger health assistant in critical conditions(system architecture is analogous)
Priority Level
Essential
Scenario(s)
The user wears dedicated sensors measuring his/her vital signs (e.g.: heart rate, blood pressure, body temperature, etc.). The sensors are connected to a control unit that collects the data. This unit will be generically called “in-vehicle system”, and it could be the vehicle own telematic unit, or the unit + a PDA, etc.
At a certain time during the travel, the user is sick or wants to check his/her own health status. Through a dedicated in-vehicle HMI, he/she sends a health monitoring request to the service centre.
System output
The data measured by the wearable sensing system are collected by the called in-vehicle system and transmitted to the health care centre.
The latter evaluates the received information and sends an answer back to the called in-vehicle system. The response is delivered to the user, for instance by means of the vehicle HMI. An example of such service could be the establishment of a voice connection with the medical assistant.
The main difference between a standard phone call and the present service is that the current health data are provided in advance with respect to the call.
Relevant OASIS WP
WP3.4, WP2.6
Services involved
Driver telematic support
Health monitoring
Devices & restrictions
11a. User Interaction devices & restrictions
Portable device (tablet PC, mobile phone, tbd) Vehicle Telematic Unit
11b. Sensor devices & restrictions
Health monitoring wearable sensors
Critical success parameters
Services
Success parameters
Driver telematic support
Efficiency and reliability of data transfer and communication system (i.e.: transmissions from the vehicle to the emergency centre or service provider and vice-versa).
User friendliness of the peripherals/HMI system.
Health monitoring
Accuracy and reliability of the sensor acquisitions.
Environmental restrictions
Potential problems concerning data transmissions, based upon the GSM/UMTS network (i.e.: lack of coverage within certain areas, for example in tunnels).
Interaction level
Step 1 – The user feels ill or simply would like to check his/her own health conditions.
Step 2 – The user asks the system for help. This could be done in a very simple way, with one single command
Step 3 – The in-vehicle system transmits the data read from the sensors worn by the driver to the health care centre.
Step 4 – The health care centre sends a response to the in-vehicle system.
Step 5 – The service centre delivers the response to the user, for example through the establishment of a voice link with the medical assistant.
Personalisation/ adaptation level
Yes:
static parameters: static user profile (i.e.: name, date of birth, etc.)
semi-dynamic parameters: user’s case history and medical data (i.e.: known pathologies, allergies, etc.)
dynamic parameters: current values of the user’s health parameters acquired by the wearable sensors
environmental parameters/context of use: driving
Quality of service indicators
We shall refer to the performance criteria discussed in Personal mobility UC1 (Driver/passenger health assistant in critical conditions), and consider them as an upper bound to the QoS indicators of the present UC, which is less safety critical than UC1.
Potential input needed from other UCs (what input and which UCs?)
Important accessibility attributes (per UG)
The design of the HMI structure, including connected peripherals, must take into account the elderly user needs.
The health monitoring and assistance request functions must be always available and working.
Background info/ reason on selection and on assigning the priority level
For elderly people, being aware of the presence of a medical assistance service, which can easily and rapidly be accessed while driving, is a factor that can guarantee an improved safety and confidence level. For example, the service could encourage them to undertake trips that they would not do without remote assistance.
References
Comments
Within OASIS, the approach based on wearable sensors and on data fusion of various sensor inputs, combined with user’s personalized information, is considered the most significant innovation.
Figure 87: SP3-25 Driver/passenger health monitoring on demand