Fall Detection-Prevention Functionalities and Operative Protocols

CIP-297225
Deliverable 2.2
I-DONT-FALL Fall Detection/Prevention Functionalities and
Operative Protocols
Angelo Maria Sabatini

Vincenzo Genovese
Due date of deliverable: 15/02/2013

Actual submission date: 15/02/2013
Resubmission date: 15/02/2013
This work is partially funded by EU under the grant of CIP-Pilot actions 297225.
I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 1 of 111

Change History
Version Date Status Author (Partner) Description
0.1.0 07/08/2012 Draft V. Genovese (SSSA) Index of the deliverable
and description of the
A.M. Sabatini (SSSA)
contribution expected for
each section.
0.1.1 08/08/2012 Draft S. Rizou (SiLo) Comments on the

structure of the
M. Melideo (ENG)
deliverable and
suggestions to improve
it.
0.1.2 10/08/2012 Draft V. Genovese (SSSA) New index of the

deliverable according to
the comments received.
S. Rizou (SiLo)
0.1.3 28/08/2012 Draft V. Genovese (SSSA) First draft that includes

the description of some
services and protocols
S. Rizou (SiLo) as examples for the
partners to give their
contribution.
0.1.4 06/09/2012 Draft C. Zaccarelli (ASL) Draft that includes the

requested contributions.
P. Giacomelli (TESAN)
E. Rull (UPC)
0.1.5 13/09/2012 Draft A.M. Sabatini (SSSA) Draft that includes the
requested contribution.
S. Rizou (SiLo)
The sections that report
and describe the pilot
protocols are
restructured and
rewritten.
0.1.6 14/09/2012 Draft M. Melideo (ENG) Comments on the new

structure and content of
the deliverable.
0.1.7 17/09/2012 Draft P. Levene (DOCOBO) Draft that includes the

S. Hope (DOCOBO)
0.1.8 19/09/2012 Draft A.M. Sabatini (SSSA) The Introduction is

revised and the
document is submitted to
ageneral revision.
0.1.9 20/09/2012 Draft S. Rizou (SiLo) Draft that includes the

C. Barru (UPC)

0.1.10 21/09/2012 Draft V. Genovese (SSSA) Sequence diagrams
edited and refined.
0.1.11 23/09/2012 K. Giokas (SiLo) Comments on the

structure and content of
S. Rizou (SiLo)
the deliverable and
additional contributions
revised.
0.1.12 26/09/2012 Draft P. Levene (DOCOBO) Version with additional

contributions revised and
R. Plumbridge
tuned.
(DOCOBO)
0.1.13 30/09/2012 Draft A.M. Sabatini (SSSA) Version revised on the

basis of all the
contribution and
received from the
partners.
1.1.0 02/10/2012 Draft A.M. Sabatini (SSSA) Version submitted to the

peer internal review.

basis of the outcome of
the peer internal review
and of the contributions
from all WP2 partners
1.1.2 12/10/2012 Draft M. Melideo (ENG) Further comments and

revision requested
S. Rizou (SiLo)

basis of the comments
received
1.2.0 14/10/2012 Final A.M. Sabatini (SSSA) Final version ready for
submission
1.3.0 15/02/2013 Final A.M. Sabatini (SSSA) Final version ready for
resubmission, replies to
M. Melideo (ENG)
the recommendations
R. Stamatia (SiLO) from the Reviewers were
R. Annicchiarico (FSL) provided.

EXECUTIVE SUMMARY
The aim of this deliverable is to provide a description of the functionalities of fall prevention
and detection services to be implemented in the IDF platform. These services will be
available to the pilot sites for providing assistance to the elderly people that are involved in
the clinical trials planned for validating the IDF platform.
The first part of the document provides an overview of the main services in a functional
and a technical view, respectively. This is an important step in the direction of
understanding how the various hardware and software parts will be integrated. The
integration work will take place in other tasks of the IDF project.
The second part of the document presents the fall prevention and detection services from
an operational point of view. After that, the generic pilot protocol that will be followed
during the medical study is overviewed and the fall prevention and detection services are
described through the presentation of operative protocols specific to the use of each
service.
Other services to be implemented in the IDF platform, namely the fall management
services, will be discussed at length elsewhere, specifically in D2.3 Definition of Fall
Management Platform and Integrated Services.
Reading guideline for resubmission
Recommendations from Review M9 that prompted modifications to the D2.2 version
submitted to the Commission are the following:
Recommendation 3
Since fall detection will be performed only where a call centre service is available, the pilot
protocol Automatic Family Notification was deleted from the resubmitted D2.2 version.
Recommendation 4
The maturity of the WIMU technology was defended in the face of the long-term goals
pursued by the IDF consortium. See added/modified parts at pag. 13, 14, 15, 17, 18, 51.
Recommendation 12
Physical training (gait/balance) protocol (including placebo activity to control the subject-
expectancy effect) was reported in the Annexs to the resubmitted D2.2 version. Moreover,
a specific comment by the Reviewers about D.2.2 concerned the need to be less generic
as far as the capability of the various pilots to implement the detection/prevention services
offered by the IDF platform. In this regard, see added/modified parts at pag. 48. Two
further references were also added.

Document Information
CIP Project 297225 Acronym I-DONT-FALL

Number
Full title Integrated prevention and Detection sOlutioNs Tailored to the population
and risk factors associated with FALLs
Project URL http://www.idontfall.eu/
Document URL
EU Project officer Bart Neerscholten
Deliverable Number D2.2 Title I-DONT-FALL Fall Detection/Prevention Functionalities

and Operative Protocols
Work package Number 2 Title Service Definitions and Pilot Specifications
Date of delivery Contractual 15/02/2013 Actual 15/02/2013

Status Version 1.2.0, dated 14/10/2012 final
Nature Report Demonstrator Other
Dissemination Public Consortium
Level
Abstract
(for dissemination)
Keywords Fall Detection/Prevention, Architecture, services
Authors (Partner) Angelo Maria Sabatini, Vincenzo Genovese

Responsible Angelo Maria Sabatini Email angelo.sabatini@sssup.it
Author
Partner SSSA Phone

TABLE OF CONTENTS
EXECUTIVE SUMMARY ........................................................................................... 4

TABLE OF CONTENTS ............................................................................................ 6
GLOSSARY ........................................................................................................... 8
1 INTRODUCTION................................................................................................. 10
2 DESCRIPTION OF FUNCTIONS AND SERVICES..................................................... 12
2.1 The WIMU functions and services .......................................................... 13
2.1.1 Goal.................................................................................................. 13
2.1.2 Target Population ............................................................................. 13
2.1.3 Functional View................................................................................ 13
2.1.4 Technical View ................................................................................. 14
2.2 The i-Walker functions and services ....................................................... 18
2.2.1 Goal.................................................................................................. 18
2.2.3 Functional View................................................................................ 19
2.2.4 Technical View ................................................................................. 19
2.3 The TESAN Call Centre functions and services ..................................... 21
2.3.1 Goal.................................................................................................. 21
2.3.3 Functional View................................................................................ 21
2.3.4 Technical View ................................................................................. 21
2.4 The IDF SOCIABLE functions and services............................................ 23
2.4.1 Goal.................................................................................................. 23
2.4.3 Functional View................................................................................ 24
2.4.4 Technical View ................................................................................. 24
2.5 The CAREPORTAL functions and services ............................................ 30
2.5.1 Goal.................................................................................................. 30
2.5.3 Functional View................................................................................ 33
2.5.4 Technical View ................................................................................. 34
3 OPERATIVE AND PILOT PROTOCOLS .................................................................. 42
3.1 Operative Protocols ................................................................................ 43
3.1.1 WIMU ............................................................................................... 44
3.1.2 TESAN Call Centre .......................................................................... 45

3.1.3 IDF SOCIABLE ................................................................................ 47
3.1.4 i-Walker ............................................................................................ 47
3.1.5 CAREPORTAL ................................................................................. 49
3.2 Pilot protocols ......................................................................................... 54
3.2.1 Fall detection.................................................................................... 57
3.2.2 Call centre family notification............................................................ 60
3.2.3 Provision of cognitive training........................................................... 62
3.2.4 Provision of walking training............................................................. 64
3.2.5 Patient assessment and feedback ................................................... 66
3.2.6 ADL monitoring ................................................................................ 68
4 CONCLUDING REMARKS.................................................................................... 70
REFERENCES................................................................................................. 71
5 ANNEX I PHYSICAL TRAINING PROTOCOL...................................................... 72
5.1 Physical training sessions....................................................................... 72
6 ANNEX II COGNITIVE TRAINING PROTOCOL ................................................... 89
6.1 Cognitive training exercises. ................................................................... 89
7 ANNEX III PLACEBO TRAINING PROTOCOL .................................................. 109
7.1 Placebo training exercises. ................................................................... 110

GLOSSARY
ADL Activity of Daily Living
BAN Body Area Network
BT Bluetooth
CAN Controller Area Network
COTS Commercially available Off-The-Shelf
DoW Document of Work
DTMF Dual Tone Multi Frequency
EDS Electronic Data Sheet
EHR Electronic Health Record
FD Fall Detector
FDM Fall Detector Manager
FTP File transfer protocol
GPRS General Packet Radio Service
IDE Integrated development Environment
IDF I DONT FALL
IMU Inertial Measurement Unit
IP Internet Protocol
KPI Key Performance Indicator
OS Operating System
PSTN Public Switched Telephone Network
SDK Software Development Kit
SOAP Simple object access protocol
SPI Surface Position Indicator
SPP Serial Port Profile
SUI Standard User Interface
TDM Time Division Multiplexing
UD User Diary
UDP User datagram protocol
UI User Interface
UML Unified Modeling Language
WAP Wireless Access Point
WIMU Wearable Inertial Measurement Unit

WLAN Wireless Local Area Network

1 INTRODUCTION
This document has a twofold aim: (i) to present a description of the fall
prevention and detection services for potential fallers that will be provided by
the IDF platform; (ii) to provide an insight into the operative protocols of the
services, and the pilot procedures describing how the pilot sites will trial and
evaluate the services themselves.
The description of the services include functional and technical aspects at a
somewhat high level. The content of the present deliverable adds substantially
to the information concerning services and functions already available in
previous project documents [1-2]. Here, the features of the fall prevention and
detection services for the IDF platform are described, while other services (i.e.
the fall management services) delivered specifically for medical experts and
health professionals will be faced in D2.3 Definition of Fall Management
Platform and Integrated Services.
The presentation of the fall prevention/detection services is based on the
taxonomy of services provided in [1]. This taxonomy provides a clustering of the
IDF services addressed to potential fallers together with a reference to the
technological enablers that are going to be used in the IDF platform. Although
the functionality of the fall prevention and detection services has been sketched
in the DoW and in previous deliverables, the description of services provided in
this deliverable focuses on the presentation of the technological enablers which
will realize the fall prevention and detection functionalities in the IDF platform.
Other services are provided by the IDF platform and these are called support
and monitoring services since their aim is to collect valulable information that
can be exploited, inter alia, by the fall management services for additional
analysis. However, as clarified in [1], they are taken under the broad umbrella of
fall prevention services, and as such they are also included here.
Provided the descriptions above, fall prevention and detection services are
considered from an operational viewpoint. This implies for each service the
formulation of operative protocols that describe the sequence of actions needed
for the exploitation of the service, from the initial phases of installation and
configuration to the run and maintenance phase, where the steps to maintain
the service and keep active are described. Beside operative protocols, it will be
specified how different services can cooperate in several use case scenarios,
which gives rise to a number of pilot protocols including Fall detection, Call
center family notification, Provisioning of cognitive training, Provisioning of
walking training, Patient assessment and feedback, ADL monitoring.
This document is organized in the following chapters:
Chapter 2 provides the description of the fall prevention and detection services.
For each of them, both functional and technical views for each service are
presented, without entering into any detail concerning their integration in the
IDF platform, which will be the goal of Work Package WP3 Platform and
Services Technical Specification.

Chapter 3 gives detailed specifications concerning the pilots operational
protocols and the manner they are implemented to exploit the fall prevention
and detection services of the IDF platform. For this purpose, a number of pilot
protocols are elaborated based on the use cases presented in [2].

2 DESCRIPTION OF FUNCTIONS AND SERVICES
In this Chapter information is provided for each fall prevention and detection
service in the IDF platform. The service enablers that are associated to them
have been called in [1]: (a) WIMU; (b) i-Walker; (c) TESAN Call Centre; (d) IDF
SOCIABLE; and (e) CAREPORTAL. The template employed for describing
function and services of (a) through (e) is as follows:
Goal Describe in this section the goal of the tool/service
Target population Describe the target population of the tool/service
Functional view Describe the functionalities ofthe tool/service. Present

first a list of all functionalities. Then explain each
functionality in detail in separate subsections.
Technical view
Hardware Describe in this subsection the hardware used for

providing the specific service. Provide technical
information about the dimensions, the battery
autonomy of the system (if any), security and safety
aspects etc.
Software Describe in this subsection the software used for

providing the service. Provide technical information
about OS, Baseline Software, configuration etc.
Communications Describe in this subsection the communication

Integration protocols supported by the service.
User Interfaces Describe in this subsection the user interface of the

service, namely the means by which the user gets
access to the service.
Environmental Describe in this subsection the environmental

Conditions conditions under which the tool/service can be used.
User/Physical Describe in this subsection the user/physical

Requirements requirements such that the tool/service can be used.

2.1 The WIMU functions and services
The IDF Fall Detector (FD) integrates a Wearable Inertial Measurement Unit
(WIMU) and a smartphone used as a Base Station (BS) to form part of the IDF
Body Area Network (BAN). At the heart of the IDF FD is the possibility to
acquire and store inertial motion sensor data that can be used to feed
computational algorithms aimed at detecting falls and computing activity
summaries.
The data logging capabilities and the range of computational methods offered
by the IDF FD are intended to set the stage for a reliable fall detector that can
also promote fall prevention by monitoring user activities (this feature is usually
not present in commercial fall detectors). At the current stage of development,
the limited battery lifetime of a WIMU (6 hours) is mainly due to the WIMU
controller requirements and to the need for feeding activity summaries back to
the smartphone via Bluetooth (BT). Since the main goal of the IDF project is to
offer a validated, integrated approach to the fall management problem, the
limited battery lifetime is not felt a serious technological bottleneck. A number of
countermeasures can be implemented indeed to extend the service duration, as
explained in the following. Moreover, it exists the possibility to adapt the IDF FD
implementation to the needs of specific pilots, in terms of: (a) how many
sensing elements are actually required by the methods used for fall detection
and user monitoring; (b) the computational complexity of these methods; (c) the
amount of information actually fed back to the users.
2.1.1 Goal
The goals of the IDF FD are the following: (a) to detect falls, by feeding the
threshold-based algorithms that run on the WIMU controller with data from the
WIMU sensors; (b) to raise alarms from the BS to the TESAN Call Centre (see
Section 2.3) when falls are detected; (c) to provide a limited form of ADL
monitoring by computing and storing activity summaries.
2.1.2 Target Population

Elderly people (age 65 years) with high risk of falls (Tinetti 20 and/or at least
one previous fall in the last year) living at home or in residential care are offered
the IDF FD service. The IDF FD is also exploited during the validation phase of
the IDF prevention services, namely when the elderly people are involved in the
walking training sessions.
2.1.3 Functional View

The main functions that the IDF FD fulfils are:
1. Detection of the fall of the user after impact with the ground has taken
place;

2. Transmission of an alarm message linked to a file containing WIMU
sensor data and current WIMU configuration data to the TESAN Call
Centre that is responsible for managing the fall events in the IDF platform;
3. Collection and storage of sensor data from the WIMU sensors;
4. Computation of activity summaries for ADL monitoring purposes.
The fall detection algorithms running in the WIMU controller can detect falls
based on time-localization of acceleration magnitude peaks due to impact,
provided that the posture of the faller is horizontal during the post-fall phase [3].
2.1.4 Technical View

i) Hardware
The IDF FD is based on the integration of two devices, a WIMU and a
smartphone, networked so as to form a BAN. Communications over the BAN
are based on Bluetooth technology. For technical reasons mainly concerning
the software development that is currently undergoing, the smartphone must
run an Android Operating System (OS).
The WIMU is a battery-powered electronic device with the following main
features:
1. Integrated sensors:
a. A 3D accelerometer Bosch BMA180 sensing range from 1 g to
16 g (1 g = 9.81 m/s2); 14 or 12-bit ADC conversion;
b. A 3D gyroscope Invensense ITG-3200 sensing range: 2000
/s; 16-bit ADC conversion;
c. A 3D magnetic sensor Honeywell HMC5843 sensing range from
0.7 Gauss to 6.5 Gauss; 12-bit ADC conversion;
d. A barometric pressure sensor Bosch BMP085 for altitude
measurement sensing range: 0-9 km; 16-bit ADC conversion.
2. Controller
Two models of the controller have been specifically developed: the Low
Power (LP) model is based on the NXP LPC1711U24, which runs at 48
MHz; the High Power (HP) model is based on the NXP LPC1768, which
runs at 96 MHz. NXP LPC1711U24 and NXP LPC1768 are cortex M3
microcontrollers for embedded applications featuring a high level of
integration and low power consumption (www.nxp.com).
Basically, the difference between the LP and the HP models is that the
power consumption is lower in the LP model than in the HP model, while
the computational and memory capabilities are higher in the HP
model.
3. Wireless connectivity (Bluetooth)
4. Data logging capability

5. Size 60 x 30 x 20 mm
6. The battery life (guaranteed) is at least 6 hours with a current absorption
estimated in 100 mA (this figure actually depends on how the system is used,
e.g., the BT connection is active or not). Battery and battery charger are
integrated in the WIMU; the battery charger is accessible from outside via a
standard USB port.
When the detection service duration exceeds the 6 hours of the WIMU battery
lifetime, the advice is to pair two WIMUs to the smartphone: while one WIMU is
subject to the recharge cycle, the second WIMU is always ready for service.
The availability of two distinct WIMU boards that differ just in the model of the
controller embedded into them is consistent with the IDF approach, which aims
at validating the IDF approach as a whole, rather than merely testing each
single piece of the platform: in other words, the decision to seize the trade off
bewteen computational power and energy consumption will be deferred to later
stages during the development of the IDF platform. This phase will be driven by
the specific technical requirements of any pilot, and in preparation of
commercial exploitations.
Main features of the smartphone are:
1. Availability of several wireless communication channels (Bluetooth,
GSM/GPRS/3G, IEEE 802.11 b/g/n);
2. Large amount of memory;
3. Significant computing resources;
4. Additional sensing an Inertial measurement Unit (IMU) with 3D
inertial/magnetic sensors is integrated in the device;
5. Availability of a Human Machine Interface (HMI), which can use
different means of information feedback to the user (text, images,
audio and vibro-tactile feedback);
6. Minimum battery life of about 8 hours in conditions of normal use, with
screen brightness set to maximum.
The smartphone used in the current implementation of the IDF FD is a
Samsung Galaxy SII GT-I9100. In order to extend the time period of
smartphone use, a number of tricks will be considered: in particular, the screen
brightness can be dimmed down, and an additional battery can be easily
plugged to the smartphone, at the expense of a farily moderate increase of its
weight, size and cost.
ii) Software
The software that runs on the WIMU controller has been developed using a
Software Development Kit (SDK) that supports a C/C++ programming
environment including peripheral abstraction.
The WIMU controller manages the following activities:

1. Sensor data acquisition according to the parameter configuration stored in
the WIMU Electronic Data Sheet (EDS);
2. Running the fall detection algorithms;
3. Sensor data logging on the WIMU local memory;
4. Fall alarm raising and logged sensor data transmission to the smartphone-
based BS using the Bluetooth connection.
The WIMU EDS is a text file stored on the WIMU memory, which contains any
information necessary to set the following parameters:
1. Sampling frequency (in the range 50-200 Hz);
2. Sensing range of the WIMU sensors;
3. Bandwidth of the digital low-pass filters that are used to remove some
electronic noise from sensor outputs;
4. Threshold values used by the various algorithms developed for fall
detection and computation of the activity summaries.
The piece of software running on the smartphone, called the Fall Detector
Manager (FDM), has been developed using the Eclipse Integrated Development
Environment (IDE) for Java. The Android OS is vers. 4.0.3.
The FDM module performs the following activities:
1. Automatic setup and activation of wireless communication sub-systems (Wi-
Fi, Bluetooth);
2. Parameter setting in the WIMU EDS;
3. Data reception from the WIMU sensors;
4. Fall alarm message reception from the WIMU controller;
5. Setting of the User/Device configuration received from the Tablet User
Interface (UI);
6. Data transmission to the IDF server;
7. Fall alarm/warning message transmission to the TESAN Call Centre and to
the IDF server.
iii) Communications Integration
The WIMU and the smartphone are connected by means of Bluetooth using an
SPP (Serial Port Profile) working at 115200 Hz. During normal operations the
WIMU uses the communication link for the following activities:
1. Fall alarm message transmission to the BS;
2. Sensor data transmission from the WIMU internal memory to the
smartphone memory.
The smartphone plays the role of a bridge between the BAN and the remaining
components of the IDF platform. Because of this and in order to extend the
workspace of the end user, the smartphone must provide further communication

services over the IDF Wireless Local Area Network (WLAN) and over the
GSM/GPRS/3G channels:
1. FTP (File Transfer Protocol) client for managing the Read/Write access to a
remote data repository;
2. UDP (User Datagram Protocol) server for managing commands that
originate from other IDF WLAN nodes;
3. SOAP (Simple Object Access Protocol) client for managing the access to
the Web Services offered by the TESAN Call Centre;
4. SMS (Short Message Service) text messaging service, which allows
communications with remote users.
iv) User Interfaces

The IDF FD UI revolves around the smartphone Input-Output (IO) capabilities:
touch screen, audio and vibro-tactile devices.
After the smartphone power-on and the end user authentication procedure the
FDM starts running, Fig. 1. When the WIMU is connected to the smartphone, an
indication is reported at the bottom side of the screen, showing the WIMU
battery level (97%, in the present case). The horizontal bar circled in red in Fig.
1 indicates the activity level of the end user (ADL monitoring).
Fig. 1: Screenshot of the IDF FD UI.

In case that a fall is detected an alarm message is sent to the TESAN Call
Centre and a warning message is also written on the smartphone screen.
A warning message is written on the smartphone screen anytime either the
WIMU or the smartphone present a battery life less than 30%. This warning
message will be valuable to the caregiver, or the user herself, to plan the WIMU
replacement, as prescribed by the WIMU operative protocol, see 3.1.1. Using a
double-battery package, the smartphone service lifetime can be extended to
cover the active part of the day (18 hours). The gauge of the smartphone
battery level allows programming recharge operations on the smartphone when
needed.

v) Environmental Conditions
The end user workspace is either an indoors environment (home or residential
care) or an outdoors environment (sheltered from rain, since the WIMU case is
not waterproof). Both environments must be within the range of the Wi-Fi
devices (based on IEEE 802.11 standard) that form the IDF WLAN.
vi) User/Physical Requirements

The end user physical requirements for using the IDF FD services are the
following:
1. The WIMU must be worn at the waist level;
2. The smartphone can be operated using voice and touch-screen.
2.2 The i-Walker functions and services
2.2.1 Goal
The i-Walker is designed to help and supporta user with some mobility
impairment, Fig. 2.
Fig. 2: The i-Walker.

Besides, data referred to user movements and accelerations are collected for
further analysis.
The i-Walker target populations are elderly people with high risk of falls. The i-
Walker is also used for people recovering from strokes or injury.

Five main services are provided by the i-Walker platform. Three are related to
elderly/impaired assistance. The fourth is used for data logging and the fifth is
for communication purposes. Assistance tasks should be planned by a
physiotherapist. Services provided are:
1. Active motor assistance to compensate lack of muscle force on climbs;
2. Brake assistance to compensate lack muscle force on descents;
3. Active differential assistance to compensate unbalanced muscle force.
and finally:
4. Recording of sensor measurements and actuators activities for later
evaluation (left and right hand forces, normal forces, hand-brake status, tilt
and odometry);
5. Sending data and status to networked devices. Data related to user
activity, forces measured and i-Walker status will be published to IDF
present devices and remote servers.
i) Hardware
The i-Walker is based on a standard rollator frame improved with sensors and
actuators. The following components are used in the i-Walker construction:
a standard rollator frame sized 500mm (W) x 600mm (L) x 850mm (H);
two 150W hub motors, 100mm diameter, embedded on the rollator rear
wheels;
two modified handlebars with brake handle and force measurement;
32 strain gauges mounted in 8 bridges to measure handlebar forces (X-
Y-Z) and normal wheels forces (F);
PGA signal conditioners for strain gauge measurements;
battery packs providing an autonomy of at least 4h (continuous usage);
an accelerometer circuit for inclination measurement;
eight microcontroller boards based on Microchip DSPIC 30f4011 for i-
Walker control: two motor controllers, two handlebar controllers, two
normal force controllers, one battery monitor board and one data
logger/communications interface;
a SPI to Bluetooth / WIFI communication interface for microcontroller;
a CAN bus communications network to connect all the microcontroller
boards;
DC-DC voltage converters to provide energy to the different modules.

ii) Software
the 8 Microchip microcontroller based boards are programmed in C
Language using C30 compiler integrated on MPLAB environment;
each board has specific functionalities: AD conversion, SPI interface,
digital interfaces, PWM outputs, and a common bus CAN
interface;software routines for all these functionalities are implemented
in a common C library resource and linked when necessary;
all the boards implement watchdog services to avoid hang-up problems
and answer to CAN bus status requests;
the control strategies, user assistance and data recovery tasks are
distributed along the network of microcontrollers.

Either Bluetooth interface or WiFi interface can be provided by i-Walker using
the appropriate microcontroller interface module;
Bluetooth interface will be mainly used to send data like: measured forces on
handlebars, i-Walker inclination and speed.These data can be useful in order to
detect falls.
WiFiinterface can be used to send the data sensed by i-Walker sensors to the
IDF databases for i-Walker usage statistics and maintenance purposes.
iv) User Interfaces
i-Walker can be used as a conventional walker; when powered, it runs
automatically the algorithms selected and configured by the caregivers; the
only user interaction with the i-Walker is by pushing/holding the handlebars, the
system response will be motor, brake or differential assistance.
Fig. 3: A screenshot of the interface available to users of i-Walker for control parameter
configuration.

The i-Walker device has been designed to be used mainly indoors and in (near)
flat surfaces. Outdoors usage is possible in controlled conditions where i-Walker
is not exposed to rain/humidity.

The requirements for using the i-Walker in the IDF context will be determined by
the doctors/caregivers.
2.3 The TESAN Call Centre functions and services

2.3.1 Goal
The obvious goal of the TESAN Call Centre is to alert as fast as possible of a
patient falling. Up to now all the service is integrated within a platform where the
main sensor is a panic button.
The patient is equipped with a big red button that he/she can push in case of
falling. After the triggered event is received the TESAN Call Centre starts
operating.
Right now the TESAN Call Centre is managing 34000 patients where the 2nd
and 3rd percentile is of persons the range of 85/89 years old.
The different parts of the TESAN Call Centre system can be summarized in the
following list
Receivers: these are the hardware/software infrastructures able to
receive alerts and triggers from different sources both hardware and
software.
Storage and software: this is the platform where all the different source
alerts are stored. Once stored they are automatically displayed in a
round robin methodology to the call center operators.

i) Hardware
The hardware composing the platform offer two main features: connectivity and
high availability.
As far as the connectivity is concerned, two types of connectivity hardware
infrastructures are available. A ten line dedicated phone service is available for
all of the devices that need to be able to interface with a phone line. TESAN

Call Centre is also equipped with 4 ADSL lines that have a backup ISDN line in
order to allow connectivity in case of the drop out of the normal ADSL line.
Considering the infrastructure all the servers are managed by a virtual
environment and with a nightly ISO image save to allow a fast restore in case of
server unavailability. The backup is stored in a remote location so the data
center does own only a copy of the virtual machines.
The main database servers are also replicated in a remote database center in a
high transactional frequency environment. So even if the main database server
gets corrupted it is possible to fast re-route all requests to another database
server.
The data center is equipped with air conditioners to avoid any overheating of
the machines themselves.
A continuity group is present to avoid electricity overloading and in case of
electricity failure it allows the servers a safe shutdown in a time of twenty
minutes.
ii) Software
All the software have been developed using IIS and ASP.NET technology
coupled with Microsoft SQL Server as database backend.
Even if all the software is not certified for medical purpose it has been built upon
a framework that is the only one that receives medical certification.
For the application server c# 3.5 framework have been used and the database
version is the 2005 enterprise edition.

The TESAN Call Centre provides the following protocols for alert receiving:
https, http, soap, wsdl, PPT (by phone line), stomp.
The I-DONT-FALL integration will be built using web-service technology so as
to have the maximum in terms of flexibility for the future developments of the
system and the future integrations with software written without the Microsoft
tools. Other communications integrations within the DOCOBO platform and with
other Electronic Health Record (EHR) medical software have been also
developed.
iv) User Interfaces

The patient does not have any user interface, while the call centre operator has
a web page that refresh automatically and a sound signal that beeps when new
falling event is detected. In the screenshot below the interface is shown, Fig. 4.

Fig. 4: TESAN Call Centre main login interface.
Since the interface is a web page HTML4 compliant, it can be used by all
computer main browsers. Some testshave been done even using
tabletsandIPADs and it seems that all pages are fully compliant.
There are no particular restrictions for using the TESAN Call Centre platform.

There are no particular user requirements for using the TESAN Call Centre
platform.
2.4 The IDF SOCIABLE functions and services

2.4.1 Goal
Ergonomic Motivating Cognitive Training System consists of a set of cognitive
training games covering all the cognitive skills and is supported by surface
computing (touchscreen-enabled) equipment. Touchscreen computers could be
either large-format screens that can be used on tables (e.g. Microsoft Surface,
now known as Pixel Sense) or standard PCs with touchscreen monitors. With
the advent of Microsoft Windows 8, touchscreen PCs and tablets (or hybrid
systems such as the new Windows Surface) become extremely convergent.
Cognitive games are related to real-life daily living activities and focus on
delivering therapeutic and medical value.

End users category includes three distinct elderly groups (aged over 65):
Group A: normal (healthy) elderly,
Group B: older adults with Mild Cognitive Impairment (MCI)
Group C: patients suffering from mild Alzheimers Disease (AD).
A detailed definition of these groups is provided in [4]. These groups are
perfectly in line with the population targeted by IDF since elderly people with
cognitive impairment are more prone to risk of falls.

In this section, we provide a list of cognitive training games (or exercise) that
will be used in I-DONT-FALL project. Some of these cognitive exercises were
already developed in SOCIABLE (Project Number: 238891 ICT-PSP Pilot Type
B) and they train mainly attention and orientation; while other exercise will be
developed especially for I-DONT-FALL project.
The existing SOCIABLE cognitive games reused in I-DONT-FALL are
described1 in the Annex II Cognitive Traing Protocol.

Here a brief overview on the technical aspects of SOCIABLE cognitive training
services is given as these are reported in [5].
i) Hardware
Regarding the hardware used for running the SOCIABLE cognitive training
software, IDF consortium will provide the following alternatives to the pilot
sites:
1) A normal PC running windows Software. In that case there is a loss of
functionality in terms of using touchscreen interfaces.
2) A multi-touch monitor (either on tablet, laptop or desktop computers)
3) A surface table providing multi-touch screen functionality.
The multi-touch devices should be compatible with the technical specifications

as described in [6].
1
Three partners of IDF project (SingularLogic, FSL and AUSL) participated also in SOCIABLE
project. According to the Exploitation Agreement of the SOCIABLE Consortium (internal
confidential document of the SOCIABLE Consortium), all SOCIABLE partners are allowed to
use the results of the SOCIABLE project for scientific reasons as input to other R&D projects.
To this end, IDF is allowed to use SOCIABLE services without any risk of IPR violations.
http://www.sociableproject.eu/

In particular, the surface laptop hardware has to be selected among the
hundreds of surface computer that are available in the market. In order to
meet the SOCIABLE requirements the PC system should comply with the
following specifications:
Large Screen (>15)
Large resolution
Easy to use and handle
Powerful processor
Windows Vista or Windows 7 environment (in order to alleviate the need
for rewriting the cognitive games and other applications for the surface
PC environment)
MultiTouch functionality, as a key to achieving an ergonomic and
motivating environment for cognitive training.
In the next, we present in more detail the specific hardware elements used in
the experiments of SOCIABLE as an illustrative example of hardware that
could host SOCIABLE applications.
Microsoft Pixel Sense

Surface SUR40 Pixelsense is a multi-touch product from Microsoft which is
developed as software and hardware combination technology that allows a
user, or multiple users, to manipulate digital content by the use of gesture
recognition. It was selected in SOCIABLE, since it had the below several
advantages compared to other tables of this category.
Natural Interactivity: Touch based interaction, combined with the
appropriate effects on virtual objects lead to a more natural and
expressive interaction. Natural interactivity is also enhanced based on
the combined use of physical and virtual objects (i.e. mixed reality
functionalities).
Multi Touch: the multi-touch technology of SUR 40 simultaneously
recognizes and responds to more than 50 discrete points of contact.
Multi-user interaction: Multiple touches allow multiple users to interact
with the surface device, which opens new horizons to multi-user
interactions beyond conventional applications. In general, the surface
belongs to the family of large-format interfaces, which allow multiple
users to interact with the same device simultaneously.
More immediate and richer user experience as a result of the fact that
end-users can manipulate the applications based on their hands. Users
can interact with the machine by touching or dragging their fingertips and
objects such as paintbrushes across the screen, or by placing and
moving placed objects.
Non-obtrusive: Surface applications tend to be less intrusive than
conventional applications. MS Surface offers an invisible interface,
which enables new ways of human machine interaction.

The most significant technical features of the SUR 40 Surface are:
Screen Size: 40"
Resolution: 1920 x 1080
Product Dimensions (Without Stand): 1095 x 707,4 x 103 mm
Number of Display Colors: 16.7M
CPU: Athlon X2 Dual-Core 245e (2.9GHz)
Weight: 36.8 Kg
To conclude, Microsoft Surface SUR40 Pixelsense can be used at any terminal
supporting Windows because the operating system (and not the hardware) is
the constraint to what has been built. Hence, this is not supported on devices
with Android and IoS.
ii) Software
The hosting environment of the main surface application is provided by an
appropriate shell. Similar to the surface table case, a specialized SOCIABLE
shell is developed in order to optimize access to and use of the applications on
the surface laptop. This specialized shell overrides the default shell of the
surface laptop, according to the following specifications:
It automates the login of the elderly obviating the need for user name and
password.
It is configurable in terms of personalized user access, i.e. providing the
ability to configure the automatic login.
It provides personalized access to the SOCIABLE applications/services,
according to the configurations of cognitive sessions performed by the
medical expert (or in general the health professional). Hence, upon
assigning a surface laptop to an elderly user, the elderly user will be able
to access only the portion of games/exercises, which have been
configured by his/her supervisor. Note however that the personalized
access should not impose any frequencies associated with performing
the exercises or completing sessions, since inhome users should have
the opportunity to play exercises at their convenience.
It provides a local database in order to enable execution of the
SOCIABLE services, without any need to connect to the care centre
database.
It provides the means for synchronizing its database with the care centre
database in terms of:
o Available games.
o Reception and installation of new games/exercises.
o Updates to the existing games/exercises (e.g., patches).
o Elderly sessions and their configuration.

It enables remote management of the surface laptop applications, based
on the remote management server of the SOCIABLE platform.
All considered, there is no difference in the S/W used/deployed and extended

between these two devices (Microsoft Surface SUR40 Pixelsense Microsoft
Surface PCs) in a programming level. However, it is clear that Surface SUR40
Pixelsense offers different ergonomics, for example the user may play the
games from different height within easy reach, maintaining a comfortable
environment for elderlies. Moreover, Surface SUR40 Pixelsense results to
different use and especially helps elderly users playing within groups and hence
socializing. Also, there is different usability of applications in the surface table
(tagged objects are used in order to login or playing Mixed Reality games).
The SOCIABLE platform makes provision for exchanging information with other
systems. These provisions include the specification of interfaces to external
systems for the purpose of exchanging information. This is particularly important
given the fact that the SOCIABLE platform is in several case expected to
coexist with legacy information systems (which are likely to be inuse in the
care/day/leisure centers and/or hospitals). Such legacy systems might include:
Doctor Information Systems (DIS).
Hospital Information Systems (HIS).
Electronic Health Records (EHR).
In order to interface the exchange information between SOCIABLE and these
systems the SOCIABLE platform includes (twoway) Web Services
capabilities. In particular:
The SOCIABLE platform includes sample client interfaces enabling the
acquisition of elderly users data from the legacy system.
The SOCIABLE platform supports Web Services providing full cognitive
history for patients.
iv) User Interfaces

Users use natural interfaces while playing cognitive games. They should
interact with on-screen contents by using both direct manipulations and
gesturesor place physical tagged objects on the surface screen that can be
automatically recognized. Some of the main features of SOCIABLE UI include:
SuperReality create a lifelike experience
ContextAwareness games that adapt to context
Touch and Direct Manipulation finger touch and physical objects
response
Virtual Objects like Physical Objects virtual objects lifelike behaviour

Use of Tagged Objects mixing of the physical and virtual worlds
Use of Untagged Objects IR-reflective detection of objects
360 degree User Interface application and UI orientation
Playful Pleasurable and Explanatory Touches high quality graphics,
smooth transitions
Progressive Disclosure create natural and realistic interfaces
Multiple Senses appeal to multiple senses (sensors)
Continuous Input continuous actions, no waiting time
More information about interfaces can be found in [6].
Screenshots of few Cognitive Games from the SOCIABLE platform are shown
below.
Fig. 5: Executive Functions Training.
Fig. 6: Orientation training.

Fig. 7: MyHome Game Category: Orientation.
Environmental Conditions
Cognitive training will be performed indoor in the institutions or in home
environment.
i) User/Physical Requirements
In order for the elderly to use the SOCIABLE cognitive training system, they
should be able to interact with the SOCIABLE applications. A typical example to
be employed in games involves pictures, images, puzzles and pieces that
should be selected and resized in the context of a cognitive training exercise. In
particular, elderly users should be able to:
touch objects and push them around (like in the real world), but at the
same time:
scale objects by using a twofinger gesture (unlike the real world).

2.5 The CAREPORTAL functions and services
CAREPORTAL is a feature packed Android Tablet with high resolution colour
touch screen, WEB camera and a range of features that make it ideal for use
with the older population. With WiFi, Ethernet, PSTN Modem and 2G/3G
connectivity options, communication across a range of rural and urban regions
is assured. It is the patient and/or end user of the DOC@HOME Telehealth
system that provides an end-to-end service infrastructure for the monitoring and
management of patients and end users remote from centres of expertise.
2.5.1 Goal
CAREPORTAL is the result of an in-depth review of societal needs and
assessment of demands on changing European and International Health and
Social Care Services. As a second generation Telehealth monitor, for use in the
home, residential care home, clinic and hospital, it is core data capturing
component of the Docobo DOC@HOME infrastructure used for remote
telehealth monitoring and assessment services. It was originally developed in
an EU Framework Programme 5 project. Current post project development has
integrated Telehealth, Telecare and Telemedicine into a single operational
platform with CAREPORTAL to:
function as the home/community monitor of the DOC@HOME system
auto-configures to provide the designated services and monitoring defined
on the WEB server. It can also be manually configured by system users to
meet their own requirements.
offer a complete prevention management and telehealth solution providing
societal and clinical monitoring of patients in their own homes capturing
early indicators of change in socio-health and mobility status.
provide early detection of change indicators that can then be used to
improve quality of life, avoid exacerbation of disease and reduce and
prevent risk of falling resulting in reduction of hospital admission.
establish a richness of data that includes new indicators of change, improve
data quality and enables a clinical and social reference framework from
which new treatments, preventative actions and approaches to care can be
developed
run a range of validated assessment tools/questionnaires that include:
Falls Efficacy Scale International (FES-I)
Short-FES-I falls assessment for use in clinical practice
SF-36; SF21 and variants
St Georges Respiratory Questionnaire
EQ-5D: a measure of health status from the EuroQol Group
HADS The Hospital Anxiety And Depression Scale

act as a means to deliver assessment questionnaires with up to 7 standard
multi-choice answers or other forms of questions include numeric scales,
numbers, prompts, vital sign measures, scored responses of similar types
directly to an end-users home
be used as a screening tool to capture information from patients with
undiagnosed conditions or non-specified levels of risk such as in falls or
stroke
function as a health, wellbeing and quality of life, social networking to reduce
social isolation and to extend across the digital divide to deliver eInclusion to
vulnerable people and an ageing population.
In summary, CAREPORTAL has been designed specifically to meet the

physical and cognitive needs and abilities of a wide range of users. It meets the
requirements of the Medical Device Directive as a Class IIa Medical Device,
ensuring it can be legally used by health organisations to collect, monitor and
diagnose health related data. It is equally suitable for social care use and the
latest social networking technologies supporting people in the community.
CAREPORTAL is part of the DOC@HOME system that forms the basis of the
IDF platform and will be used to capture data that supports prevention of falls in
the community.

Over the last few years a policy shift in European Member states has been
conceived to transfer management of patients into the primary care setting
where they will be managed without the need to involve hospital attendance and
to minimise and/or reduce in-hospital stay. The nature of this policy shift, to
accommodate changes in demographics and to reduce demand on limited
resources, is to move the emphasis away from an alert intervention
management system to one that is based on prevention.
In the context of the I-DONT-FALL project, CAREPORTAL functions as a home
HUB that can capture information directly from the End User, from other
devices such as the i-Walker and WIMU and can receive information passed to
it from call centres including that run by TESAN.
Patients with long Term Conditions
Patients that develop long term conditions may have evolving complex care
needs which reach across different social and clinical areas. New integrated
care technologies that will be demonstrated through the IDF platform allow
specialist care to be delivered to such patients in their own homes.
The elderly well
As the balance shifts towards a higher percentage of the elderly in the
population, there is an increasing move for people to become more involved in
the personal health maintenance. The increasing proportion of elderly is also
associated with increased isolation and an increased risk of falling.

Prevention of injury of elderly and vulnerable people
One of the highest costs for healthcare and social care providers occurs when
elderly and vulnerable people fall. Falls and the perception of a high Risk of
Falls have a incapacitating effect on the people at risk. Prevention of injury is a
high priority area. Examples include fracture of the neck of femur which is
associated with high demand on services, reduced quality of life, prolonged
hospital stay and long term recuperation, but may also result in the death of the
patient from infection, pneumonia and shock.
Management of medication
Many falls are the result of inappropriate medication or the side effects of
medication. The CAREPORTAL provides access to specialised components
within DOC@HOME which address such causes.
Promotion of self management and empowerment
Empowerment to self-manage is a major pathway to deliver greater confidence,
reduces anxiety and depression and provides a capacity for improved care with
associated reduced risk of falling.
Education, skill training and remote rehabilitation
These are approaches to deliver greater efficacy in telehealth outcomes whilst
also providing such services at greatly reduced cost using remote management
technology. These strategies are particularly designed to address the needs of
post stroke patients, people with long term condition rehabilitation needs and
falls prevention for the vulnerable and elderly.
Periodic assessment to determine risk of falling
Mobile community services offered by clinicians, district/community nurses can
use CAREPORTAL to capture relevant information on a frequent basis during
home visits. In the UK alone, there are over 36,000 registered general
practioners supported by 23,000 practice nurses, and over 3 million people
receiving treatment from District Nurses.
Care Homes
It is known that there is a higher incidence of hospital admission from patients in
care homes which also have a higher prevalence of falls when compared with
patients in their own homes.In over 69% of the cases, poor health is one of the
reasons for patients being transferred to care homes. These patients have the
highest pro rata incidence of falls than any other population group.
Occupational Health
Loss of workdays through accidents at work and absenteeism is high. 28m
working days are lost due to work-related ill health, and 7m due to workplace
injury. Docobo has developed state of alertness tests, that detect if the
alertness of high risk employees is reduced below a norm, whether caused by
drink, drugs, fatigue or stress. Falls and injury events can be reduced through
good management.

CAREPORTAL is placed in patients homes, clinics and residential care
facilities where information on health and wellbeing is gathered and transferred
to the telehealth service DOC@HOME platform.
Information is gathered through answers to a range of clinical assessment
questionnaires and vital signs, configured to the needs of each patient. Specific
measures are included that allow clinicians to assess patients across all long
term conditions and applied social care needs. It is specifically geared to the
development of prevention based care programmes.
Clinicians are able to view trended information and receive alerts, interact with
patients, carers and family members. Text messages can be sent directly to the
patient at home where they appear on the hubs message screen.
It can be dedicated for single patient or family use; multi-patients in clinics and
residential care, and as a mobile system for community matrons and district
nurses. All patient related information is secure and meets the requirements of
the Data Protection Directive.
Alert messages to staff can be documented in an intervention and action log
that is correlated against monitored symptomatic and clinical trends.
In the context of I-DONT-FALL the DOC@HOME Platform and the
CAREPORTAL provide the system hardware and software infrastructure
context for I-DONT-FALL to function as a delivered platform.
Examples of typical CAREPORTAL screens are shown in Fig.8 below.
Fig. 8: I-DONT-FALL Example Log-on and Falls prevention Questions.

The CAREPORTAL is the access device comprising:
CAREPORTAL remote home monitor
DocoboAPPs personalised telehealth and telecare applications
DocoboTelehealth Question Sets and Measures
DOC@HOME Secure WEB Clinical Interface
Rehabilitation, interactive testing and learning
Health and Wellbeing Social Networking
The configuration for IDF platform services is dependent on the data capture,
measurement and application deployment variants in individual pilot sites. Any
or all combinations are possible.
i) Hardware
The CAREPORTAL is designed, developed and manufactured within the
European Union to the stringent requirements of the Medical Device Directive
offering the following specification:
1.2GHz dual core CPU
PLS TFT LCD VGA (7, 640 x 480 pixels); Capacitive touch screen
Internal Memory (Maximum)16Gbytes
Audio Formats Supported 3GP / AAC / AMR / ASF / MPEG4 / MP3 /
WAV / WMA / 3GA / AWB / FLAC / MID / XMF
Video Player: 3GPP, ASF, AVI, MP4, WMV, FLV, MKV, WebM ;Video
Recording: HD (Recording);
Video Streaming
Video Telephony: H.264
Camera - Webcam, Optional rear camera for photos with Effective Pixel
Resolution: 3.0Megapixels
Communications: Wireless: WiFi 802.11, Bluetooth , 2G and 3G options;
Ethernet, POTS dialup modem
Interfaces: Ethernet and5 x USB
Network communications: Network Comms: GSM/EDGE/3G/GPRS
GPS
Android operating system
Power: Internal rechargeable lithium Polymer battery: External 12 Volt
dc, 2.5 amp
Environment: Operating temperature: +4C to 40C; Storage
temperature: -5C to 50 C; IP Rating: IP20; Size in mm: H115 x W195 x
D30

Fig. 9: The CAREPORTAL Cradle and Monitor showing front and back USB inputs.
ii) Software
DOC@HOME Software
The software provides a secure WEB access to the programme that enables
registering of organisations, assignment of authorities, configuration,
assignment of applications, assigning alert conditions, enrolment of patients,
viewing of the patients health diary, logging of interventions and notes,
interrogation of the recorded data and transfer of patient and user data to third
party ICT systems. DOC@HOME uses Windows Server 2008 R2 operating
system.
CAREPORTAL software
CAREPORTAL provides an Android framework running on Linux operating
system. CAREPORTAL is a dumb machine until the application specific
software is loaded. In practice it utilises the front end UI of the DOC@HOME
platform. All set up control functions are made on the server which configures
the software in a series of applications which have defined functionality. When
this is completed and confirmed CAREPORTAL connects to the server and the
defined programme is uploaded.
ECG (Lead I) recording, Heart Rate, Pulse Rate, Respiration Rate, Heart Rate
Variability, Aortic Blood Flow are standard and form an important and effective
part of the Docobo Falls Prevention application.
Additional standard parameters are Pulse Oximetry, Blood Pressure and
Activity Monitoring. Inputs from residential Telecare Alarm systems can be
made directly to CAREPORTAL cradle for signal analysis and patient profiling.
Connection of other Sensors and Products (e.g. i-Walker10 and WIMU)
These devices can be wirelessly linked using the interoperable scripting
interface being developed to integrate all the disparate elements of the IDF
platform.
Application specific programmes - languages

Docobo offers a range of application specific programmes comprising clinical
accepted question sets and data capturing of vital signs. The server default
language will be English. The Pilot sites units will use the designated language
of their country. Once the final question sets are agreed (in detail) they will need
to be translated in to the local languages. This is a simple text translation
exercise only. The Docobo systems are already set up to incorporate these
translations.
Management areas
Questions and their given responses are the mainstay of the system The
principles of remote management applied to care in the community using
information and communication technology (ICT) can be separated into distinct
roles, namely to:
Assess and verify impacts on a patients condition and environment
Identification of progression or regression in a patients condition
Indication of changes in risk both progressive and sudden
Alert indication when pre-determined limits are met
Predictive indicators of pending change
Impact of side effects resulting from treatment
Enhanced quality of life
Patient empowerment to self-manage
Effectiveness of medication and therapy
Resource management
Symptomatic Question sets available

Standard Docobo Questions Categories available to IDF. Each category has a
number of questions which are associated with each category type.

Category Name
Abdomen Falls
Advice Fatigue
Angina General Health
Anxiety/depression Infection
Appointments/attendances Life style
Assessment/tools-self assessment Medication
Assessment/tools-Telehealth Micturition
Assessment/tools-Quality of Life Mobility
Blood chemistry Oedema
Bowel Pain
Breathing Pregnancy
Carers Quality of life
Chemotherapy Rehabilitation
Circulation Satisfaction
Cognitive response Sensation
Cough Stomach
Depression Syncope
Diet and fluids Therapies
Ear nose and throat Tremor
Endocrine Vital signs
Enrolment Weight
Exercise Wounds
General Health
Clinical operational area questions sets
Questions can be created at anytime and for any purpose. Generally
questions are grouped together to form a Package which is usually
aimed at assessing a patient within a defined clinical or social context
Packages are groups of questions and measures that can be configured
for specific assessment purposes i.e COPD, CHF, Diabetes or Falls
Prevention etc.
IDF-Special purposes, for example i-Walker can be validated and its
impact on patients assessed by combining its technical performance with
a series of questions assessing the patients perception on a day by day
basis alongside objective assessment.
Different settings and patient conditions can demand different questions
so that assessment is always context sensitive.
IDF clinical group can specify what questions are to be asked and when.
These can be IDFs own questions or can use any combination(s) of
standard Docobo questions.

Diagnostics and problem solving - changes in risk assessment. All questions
contribute to achieving a view of the health and wellbeing of a patient and or
assessment of a patients situation that may impact on the delivery of care.
Question Set Name
CHF Advanced Fall detection Neuro Parkinsonism
CHF End stage Fall prevention Pain
CHF Standard Gastroenterology Palliation
COPD Advanced Health and Wellbeing Palliative care
COPD End stage Health assessment Rehabilitation
COPD Standard Home chemotherapy Renal
Diabetes type1 Neuro Advance Screening Hypertension
Diabetes type2 NeuroAlzeimers Screening Atrial Fibrillation
End of Life Neuro assessment Stroke Advanced
Enrolment Neuro Dementia Stroke New
Fig. 10: DOC@HOME Question and Package Library.
Respondents to questions
Responses to questions that contribute to the information about a given patient
will have a number of sources.
Patient: this is a person who is enrolled on the system and is the
subject of the care delivery programme
Clinician: this is a healthcare professional with approved access to
treat and/or manage the patients care
Carer: an authorized family member, a friend or other non-clinical
professional person who is providing care for the patient

Social worker: is a non-clinical professional care worker proving
social support.
Supporter: a recognized individual that provides support services to
the patient on an intermittent basis
Administrator: an authorized person who is responsible for managing
the care programmeand to enrol and/or remove patients from the
system.

The system supports a number of connectivity options, depending upon the
application and physical location, for integration with the overall IDF Platform.
These are summarised in the Hardware description in section 2.5.4.1 but some
background is presented below.
Telehealth Physiological Measurement Devices
The CarePortal can interconnect with external third party sensors, products and
applications as well as a range of physiological measurement devicesand
supports Bluetooth, Wi-Fi, Zigbee, Z-wave, Ethernet and USB Connectivity.
Wide Area Connectivity
The DOC@HOME Telehealth System was initially specified by the customer to
use the PSTN telephone network but unlike the mandated system for Telecare
using DTMF was able to use a V42 Circuit Switched Data Connection via the
incumbent PTT BT (British Telecommunications) supporting an IP data stream
with 256 bit encryption. This was regarded as a resilient TDM connection for
data as it provided a constant end-to-end delay.
CarePortal supports Circuit Switched PSTN Connectivity to
theDOC@HOME central system
IMS based 21CN NGN compliancy
2G GPRS Connectivity from the CarePortal to the DOC@HOME Clinical
System for standard Telehealth Applications with Roaming SIMs for
enhanced connectivity in areas prone to signal fading
WiFi (IEEE802.11) and integrated wireless 2G/3G connectivity and
Ethernet Broadband connectivity in the cradle of the CarePortal.
Smart Home Integration
Integration with activity monitoring, environmental control and home automation
systems with Smart meters, Zigbee and Z Wave are also options for device
connectivity with the CAREPORTAL.
Integration with Other Systems
Docobo provides access to the DOC@HOME Clinical Telehealth Data from a
number of proprietary GP Systems by providing secure web interfaces

integrated and themed in such a way to be part of their system and ensuring
that the Clinical Information Governance systems are maintained.
(Docobo is leading the standardisation initiative for a common Telehealth
messaging format to enable records to be transferred between systems in a
standard form which is not yet possible in the UK )
When crossing over into the Telecare and Social Care areas which in the UK
have different Information Governance protocols Docobo are able to overcome
these issues and take event data such as when the Pendant Alarm is activated
say as a result of a fall from the Community Alarm Systems or from home
systems via the CarePortal into the Clinical Telehealth Record allowing the
Clinician to correlate Telecare events with Medical data to see if there may be
an issue with the current medication.
iv) User Interfaces

The User device, CAREPORTAL in this case is shown in Section 2.5.4.1
Hardware and has the following features from a user perspective:
(a) Touch Screen This is a capacitive Touch Screen making use of the
Android graphic capabilities for a clear image and the capability of
changing the theme colours (See 2.5.8)
(b) Buttons mapped to all the input features of the Touch Screen for those
unable to use a touch screen because of their medical condition
e.g.some arthritis sufferers
(c) Multiple connectivity options as described above
(d) USB Connectivity for other access devices such as a keyboard and also
accessory trays
(e) Case shaped to ensure that connection is naturally made to the ECG
Pads when held.
(f) Cradle for Charging and Broadband, USB and Ethernet Connectivity
v) Environmental conditions
(a) Operating temperature: +4C to 40C;
(b) Storage temperature: -5C to 50 C;
(c) IP Rating: IP20
(d) Size in mm: H115 x W195 x D30
(e) Weight in grams: 346

The CarePortal is designed for holding with two hands in order to
for an ECG to be carried out under normal conditions. Other
adaptations can be made if required.
As the CarePortal can be fitted with an integrated 3G Cellular
Modem and Wifi (802.11) is also provided the CarePortal can be
carried and used independently of the Cradle outside
The CarePortal although quite lightweight can also be used on the
Cradle for those physically unable to carry the device.
Charging must be carried out with the device on the cradle.
For Fixed Broadband, USB Connections and Accessory trays and
modules the CarePortal must be used on the Cradle
The CarePortal colour screen theme can be modified to suit those
with impaired vision or dyslexia.
Voice interaction is supported.
Buttons mapped to all the input features of the Touch Screen for
those unable to use a touch screen

3 OPERATIVE AND PILOT PROTOCOLS
In this chapter the fall prevention and detection services are discussed from an
operational point of view. This will require the description of an operative
protocol for each service. An operative protocol, in this context, is the
sequence of actions to be performed to exploit each service. Operative
protocols will focus on the use of a single IDF service, e.g., use of WIMU for fall
detection. Then, a number of pilot protocols are introduced to demonstrate the
use of multiple IDF services in one use case scenario, e.g., fall detection using
WIMU and i-Walker.
Business scenarios and use cases that illustrate the use of IDF services have
been already presented in [2]. In this deliverable, the outcomes of [2] are going
to be used as a basis towards specifying in more detail the operative and pilot
protocols. To this end, some additional details on the operation of the services
are presented and possible variations of the course of actions, if any, are
discussed depending on the different service provisioning environments.
It is important to outline that the technological providers (SSSA, TeSAN,
Docobo, SiLO, UPC) adapted the operative protocols of their systems based on
the analysis of the user requirements elicited in a previous deliverable [8]. The
adaptation process was reviewed by pilots and approved. Note that according
to the medical protocol, the type of exercise performed by the users will be
identical across the pilot sites. A detailed description of the physical training
(gait/balance) protocol, which includes placebo activity to control the subject-
expectancy effect, is reported as an Annex to this document [9].
In Table 1 an overview of the association between the fall prevention and
detection services, the technical enablers and the pilot protocols is sketched.
Table 1: Association between services, technical enablers and pilot protocols.
Service Technical Enablers Pilot Protocols
Fall detection WIMU Fall detection

TESAN Call Centre Call center family notification
Cognitive training IDF SOCIABLE Provision of cognitive training
Walking training i-Walker Provision of walking training
User diary CAREPORTAL Patient assessment and feedbacks

ADL monitoring WIMU ADL monitoring

3.1 Operative Protocols
An operative protocol is divided into three phases called the Start-up Phase, the
Running Phase and the Maintenance Phase; moreover, the Start-up Phase
requires the protocol to consider two different set of actions, namely the steps
that are necessary to install and configure the service. The meaning of these
terms is detailed in the following template.
Start-up Phase Describe here the sequence of actions that have
to be performed bythe end-user and other actors
(e.g. medical experts, clinicians) such that the
tool/service can be used.
Installation
Provide here information about actions that have
to be taken once e.g. installation of baseline
software.
Configuration
Provide here information about actions that have
to be taken each time the tool/service is used e.g.
service configuration.
Running Phase Describe here the sequence of actions that have
to be performed from the end-user and other
actors (e.g. medical experts, clinicians) while the
tool/service is used.
Maintenance Describe here the sequence of actions that the
Phase end user and other actors (e.g. medical experts,
clinicians) should take such that the tool/service is
available to use (e.g. recharge protocol).

3.1.1 WIMU
i) Start-up Phase
Installation
The WIMU and the smartphone will be delivered with all software needed to
support the IDF FD services.
Software updates on the WIMU will be done as follows:
1. connect the WIMU to the PC Tablet via a standard USB port; the WIMU is
configured to work as an USB disk;
2. save the WIMU manager binary file on the USB disk;
3. remove the USB connection and turn off/on the WIMU.
Software updates on the smartphone will be done as follows:

1. copy the Application Package (APK) file concerning the FDM on the
smartphone local memory;
2. click on the APK file.
Configuration
The IDF FD service configuration requires that the following entities are
properly set:
1. text/audio message that has to be used to communicate with the end user;
2. time duration of the alarm buzz ON;
3. address and password that are needed to get access to the Web services
provided by the TESAN Call Centre;
4. address and password that are needed to get access to the services
provided by the IDF server.
ii) Running Phase

The end user is not requested to perform particular actions besides the
authentication in order to benefit from the IDF FD services.
The IDF FD service is immediately available after the completion of the
following sequence of activities:
1. WIMU power-on;
2. smartphone power-on;

3. end user authentication procedure.
Once these activities are completed, an icon (a small spin-top) will appear on
the taskbar to notify the FDM execution.
While the IDF FD service is active no specific actions are requested to the end
user beside those concerning the battery level status and the warning
messages from the smartphone.
ii) Maintenance Phase

The end user and other actors (e.g. medical experts, formal or informal
caregivers) must comply with the following battery recharge protocol:
the WIMU device must be replaced each 6 hours;
the smartphone battery must be recharged on a daily basis.
When the warning message related to the battery level of either the WIMU or
the smartphone appears on the screen, the end user and other actors (e.g.,
medical experts, formal or informal caregivers) must replace the WIMU and
recharge the battery of the removed WIMU and/or the battery of the
smartphone.
The procedure is as follows:
1 close the FallDetector app on the smartphone;
2 switch the depleted WIMU off and then remove it from the user waist;
3 take the fully-charged WIMU from the USB plug;
4 place the fully-charged WIMU on the user waist and switch it on;
5 run the FallDetector app on the smartphone and wait until BT
connession is established between the WIMU and the smartphone.
6 plug the depleted WIMU into the USB plug for recharge.
Replacing batteries of WIMU and/or smartphone and recharging imply the
complete stop of the service. Moreover, during the recharging phase, the
WIMU under recharge cannot be worn by the end user for his/her safety. The
assistance of the caregiver during these phases will minimize the risks of
incurring in falls that cannot be monitored.
3.1.2 TESAN Call Centre
i) Start-up Phase
The startup phase for TESAN Call Centre consists only in the creation of a
specific center for the IDF patients and the creation of the data so to have
assigned for every patient his UID and his/her UUDI.

ii) Installation
There are no installation procedure as the information about the web-services
that need to interface TESAN Call Centre with CAREPORTAL and the devices
have already been published.
iii) Configuration
The configuration have already been set up during the development phase.

3.1.3 IDF SOCIABLE
i) Start-up Phase
An initial installation should be done before using SOCIABLE applications. In
the next paragraphs, the initial steps needed to deploy SOCIABLE applications
are described.
Installation
Pilots should only install the software providing cognitive training services on
the surface computing equipment. This step is done once in the beginning,
when SOCIABLE cognitive training system is installed on the hardware that will
host the SOCIABLE application.
Configuration
Since each training game improves a specific skill (e.g. memory, orientation,
language), medical experts design the training program (selection of cognitive
training games) according to the specific level of deficits of the elderly through
back-office application. Through a configurable interface, the menu of available
training games is customized based on the training program of the medical
experts.In other words, configuration can be performed in an individual level, i.e.
determining a special set of cognitive exercise for each patient. For the medical
study of the IDF project, a specific set of cognitive exercises is specified that will
be followed by all patients performing cognitive training.
ii) Running Phase

In the running phase, the end user should login in the system. Then the system
displays the set of cognitive exercises that have been configured for this user.
The user starts to execute the cognitive training protocol that is formed by
exercises that are proposed in a predefined sequence until the training session
is completed. The time for performing each exercise is variable based on the
user capabilities, however the total duration of the cognitive training session is
limited to 30 min.
While performing cognitive training, the user interacts with the SOCIABLE
interface according to the context of cognitive training system. Depending on
the kind of cognitive exercise, the user follows a different set of actions. More
details on specific games are given earlier in the detailed description of
cognitive exercises.
iii) Maintenance Phase

The hardware devices should be always plugged in. There is no other action
necessary for the maintenance of the system.
3.1.4 i-Walker

i) Start-up Phase
- The i-Walker device is started by powering it on, after that it will be ready
for operation.
- If a device with Bluetooth or WiFi is in range messages will be received
from i-Walker. This service must be enabled and hardware
properlyconfigured.
Installation
All i-Walker software will be preinstalled. It will be provided with all the low level
microcontrollers programmed.
Configuration
i-Walker can be configured by setting two main parameters and . The
parameter is an offset that can be set to create a permanent resistance or i-
Walker force pushing against the user. The parameter is a gain applied to the
forces done by the user. The combination of both parameters allows the
therapists to create a patients tailored configuration. This configuration will not
be done by the patient but by the caregivers/medical staff involved in the IDF
project. Engineers will train and advise this staff.
ii) Running Phase

While the service is operating no actions are requested to the end user. i-
Walker would be fully operative while the battery were charged.

End users, caregivers or medical staff must be aware of battery state. Battery
must be recharged when exhausted and i-Walker will be inoperative meanwhile.
Standard operating time (normal walking with communications enabled) will be
about 5 hours. Recharge will long for 3 hours.

3.1.5 CAREPORTAL
In the UK the Connecting for Health Assistive Technology Programme has
analysed the envisaged lifecycle of telehealth deployments starting from initial
referral and continuing to decommissioning. From this analysis, they have
identified 9 discrete use cases relevant to the lifecycle, which are summarised
in respect of CAREPORTAL Operational Protocols under the headings as
follows:
i) Start-up Phase
Refer Patient for Assessment
Clinicians can electronically refer patients to care managers for telehealth
assessment. (This is prior to the provision of CAREPORTAL equipment in the
home of the User)
Assess patient for Telehealth monitoring
Clinicians share telehealth assessment results with other members of the care
team and if appropriate agree deployment of Telehealth equipment.
Installation
Install and commission Telehealth equipment
The clinician electronically submits an order for the appropriate telehealth
equipment from suppliers who then carry out installation and commissioning in
the patients home. The supplier then carries out user training or trains the
community nurse to install and commission the equipment and subsequently
train the user themselves.
Configuration
Enrol Patient on Telehealth system
The patient is enrolled on the system and care team members are notified that
the patient is receiving a live telehealth monitoring service.
Create/update Telehealth Care Plan
The Care Plan is created or updated and clinicians are allowed to share
details of a patients care plan with care team members
Create Telehealth Patient Record
The system is capable of auto-populating patient telehealth records by
drawing on existing sources, for example, the Patient Demographic Service
(PDS) in the UK. This allows users of telehealth systems to import existing
demographic information from central systems into the telehealth record at the
point of record creation.

The procedure is as follows:
a) Telehealth system clinical user logs into the telehealth system under
test (IDF); this process includes authentication through a single sign-
on compatible interface.
b) Telehealth system user initiates new patient registration, entering
limited information about the patient and requests a search.
c) The telehealth system contacts the Electronic Patient Record(EPR)
to find the matching patient (s) and presents the results to the user.
d) If the user identified the match they require, then the associated
information from the EPR is used to populate the IDF telehealth
system enrolment form, otherwise the user initiates a modified
search, cancels the operation or enrols the patient using the
information available to them.
ii) Running Phase

Monitor readings against Telehealth Care Plan
Care team members can routinely view a summary of patients telehealth data
in their local systems. Three test cases are envisaged:
Interactive Browsing: The telehealth system provides access to interactive
views of the patients telehealth data.
Summary Reports: The telehealth system provides access to summary
reports (in an open format such as PDF, JPEG or Open Document format)
containing the patients telehealth data in a text or graphical format that is
designed to aid fast interpretation).
Individual Events: The telehealth system provides access to individual
measurements, responses to symptomatic questions, events and details of
clinical interventions made, which the recipient healthcare information
management systems renders into a suitable display format.
A pre-requisitefor all of the test cases that follow is that a patient is registered
on both the telehealth system and the recipient health information
management system, and that these registrations can be reconciled by the
recipient health information management system.
Interactive Browsing process
a) A clinical user logs into the recipient system; this process includes
authentication through a single sign-on compatible interface.
b) The user selects a patient that has telehealth.
c) The user selects a browse telehealth data action and is presented with a
web browser window that allows them to interactively browse the patients
telehealth data using interactive views created by the telehealth system,

in the same manner as when they had logged into the telehealth system
and selected the patient.
Summary Reports process
authentication through a single sign-on compatible interface
c) The user selects a view telehealth reports action and then if appropriate
selects or a specific report (by date range and content) or specifies the
report required (by date range and content).
d) Depending upon the report format (e.g. PDF, JPEG, Open Document)
and the capabilities of the recipient system, the report is either rendered
on the users screen within the recipient application or the user is allowed
to download the report to their local file system
Individual Events process
c) The user is presented with a rendered view of the selected patients
telehealth information.This will be based on information that will have
been exchanged between the recipient and telehealth systems.
Provide care
Clinical users whose primary system is a non-telehealth system (i.e. Telecare),
are enabled to update the telehealth system with details of any patient
intervention carried out by them. These updates will then be made available to
the other members of the care team either directly through accessing the
Telehealth system or through regular updates within the patients Personal
Health Management Report (PHMR). This allows the recipients of a PHMR
(specifically a PHMR containing a request for action) to respond to the sender
of the PHMR. The process is as follows:-
c) The user selects adds a note to the patients record relating to a
clinical intervention that has been made.
d) A second user logs directly into the telehealth system and selects the
patient associated with step b.

e) The second user views the patients details and observes the
intervention note entered during step c.
Send Notification
Care team members are updated as to the status of the patient. This
functionality communicates changes in the status of a telehealth patient,
making the status available to clinicians in their local system, for example,
where a patient goes live onto the telehealth monitoring service, a message
will be sent to the care team members to update the patients telehealth status
in local clinical systems. To implement the capability the procedure is as
follows:-
a) The patient is set up on the telehealth system with state Inactive.
b) A clinical user logs into the recipient system; this process includes
c) The user selects the patient associated with step a and views their
clinical record.
d) The user observes that the patient does not have telehealth.The user
logs out.
e) The state on the telehealth system of of the patient from step a
changes to Active.
f) A clinical user logs into the recipient system; this process includes
g) The user selects a patient associated with step a and views their
clinical record.
h) The user observes that the patient now has telehealth.The user logs
out.
i) Data relating to the patient from step a is entered which causes an
event trigger to fire on the telehealth system.
j) A clinical user logs into the recipient system; this process includes
k) The user selects a patient associated with step a and views their
clinical record.
l) The user observes that the patient has an active, telehealth related
task.
m) The user processes the task changing its status from Open-
Unacknowledged to Closed, entering an intervention note to
indicated details of how the task has been completed.
n) The user logs out.

o) A second user logs directly into the telehealth system and selects the
patient associated with step a.
p) The second user views the patients details and observes that there
are no Open-Unacknowledged events.
q) The second user also observes the intervention note entered during
step m.

Battery Charging After use the CAREPORTAL is returned to its cradle for
battery recharge
Connectivity The DOC@HOME System is designed so that it can be
observed by the Clinician if:
a) Symptomatic Questions are being answered, the CAREPORTAL is
connecting to the DOC@HOME Clinical Server and the Telehealth
Record is being uploaded (Correct State)
b) The CAREPORTAL is connecting to the Server but no questions
have been answered and no record data is being uploaded. Alerts
can be generated and the clinician will take action to determine the
status of the patient.e.g. The patient may be on holiday or have gone
into hospital without informing the Clinician or Carer
c) The CAREPORTAL is not connecting to the Server and no record
data is being uploaded to the Server as a result. Alerts can be
generated and the clinician will take action to determine the status of
the patient and the equipment. For example, the CAREPORTAL has
external connectivity but is charged through the cradle and this may
be forgotten and the battery may flatten. Contact is made with the
patient to ensure that the patient is satisfactory and the patient is
advised to replace the CAREPORTAL onto the Cradle or a
maintenance visit may be made by an engineer.
Battery Replacement If the unit has been in service for some time the unit
may be required to be returned to base for a rechargeable battery replacement.
Cleaning If the CAREPORTAL is to be reallocated to a new user it is returned
to base for a clinical clean.
Hardware Fault Detection and Upgrades Should a hardware fault occur or
new hardware features become available and the authority or user wishes to
purchase these then the CAREPORTAL is returned to base.

3.2 Pilot protocols
In this section we first give a pilot protocol overview that shows the big picture of
the pilot operations in each pilot site and then we explain the pilot protocols
based on the use cases presented in D1.3 [2].
As a matter of example, consider a typical application of the IDF platform for
potential fallers. First the medical expert will check the health record of the
patient and beinformed about the health status of the potential faller. According
to the medical protocol, the medical expert will assign a rehabilitation IDF
programme to the potential faller based on the randomization process. After the
definition of the IDF rehabilitation programme, the end user will start regular IDF
sessions as specified in the medical protocol. In particular the end user will visit
the pilot site and perform his/her IDF training sessions (two sessions of 1 hour
per week for 12 weeks). During the sessions, the end user will perform his
exercises according to the IDF rehabilitation programme. After each session,
the health record of the end user will be updated with the data collected during
the training session and the medicalexpert will be able to assess the progress of
the end user. The following pilot protocols describe how the fall prevention and
detection services come to be used together during this process:
Fall Detection
Call centre family notification
Provisioning of cognitive training
Provisioning of walking training
Patient assessment and feedback
ADL monitoring
Each of them will be detailed in the following. For the presentation of the pilot
protocols depicting different use cases a template is used, which includes the
following information [7]:
Use Case ID The identifier of the use case.
Goal A longer description of the goal, if

needed.
Primary Actors and Interfaces The primary user involved in the use
case and the interfaces between him
and the system.
Secondary Actors Other actors from whom the system

needs assistance.
Initial status and precondition What we expect is already the state of

the world before of the execution of the
use case.

Trigger The action upon the system that starts
the use case. It may be a time event.
Service Provisioning Environment The environment where the service is

provisioned, namely Home, Pilot Sites
or both.
Time (Duration & Frequency) Details concerning the expected

duration and frequency of the delivered
service.
Basic flow Verbal description of the steps in which

the interactions between the actors and
the IDF system takes place in the
specific pilot protocol.
Extensions Optional steps that are added to the

main scenarios in certain
circumstances.
Sub-Variations Alternative steps that will cause

eventual bifurcation with respect to the
main scenario
Sequence diagram Interaction diagram expressed in a

Unified Modeling Language (UML) to
show how processes operate with one
another and in what order.
In order to better understand the sequence diagrams reported in the following, it

is appropriate to define here some objects that compare in them and that have
not yet been presented (in this regard, see also [2] for an insight on the top level
IDF architecture).
IDF Secondary UI Fall management services (not presented in the

present document) will be accessible by
secondary users (e.g. medical experts,
clinicians) through a Web-based UI, which will
enable the exchange of information with the IDF
server.
IDF Server This part of the IDF platform communicates with
the different services through a Communications
broker, namely a piece of software running in a
local machine. The IDF server will allow the view
of IDF data existing on either DOC@Home
and/or AREAS Electronic Health Record (EHR)
instances by querying their respective web
services.

Other terms are widely used in the following. They concern the various actors of
the IDF platform. Formal definitions for the actors are given below.
End user An individual of the target population identified

for using the IDF platform
Patient An end-user that receives medical treatment and
assistance by means of the IDF platform
User Any person who can interact withthe IDF
platform. S/he can be an end-user, a medical
expert, a system administrator
Administrator A user with the faculty to add new users to the
IDF platform
Clinician Medical expert
Caregiver A person supporting the patient during her/his
ADL. S/he can be either a patients next of kin or
a specialized person assigned to the patient

3.2.1 Fall detection
In this section the use of IDF fall detection services is demonstrated. This pilot
protocol is based on the joint exploitation of two enablers, namely WIMU and
TESAN Call Centre.
Overview
Title Fall detection
Use Case ID UC14
Goal/Purpose The end user expects to be
supported if he/she falls down.
Primary Actors and Interfaces End user (patient): WIMU UI
Secondary Actors Call centre, friends and next of kin.
Initial Status and Preconditions
Service Provisioning Environment At home and pilot site
Time (Duration& Frequency) No temporal restriction in the
service delivery within the life of the
battery systems.
Basic Flow
1. On the base of the data monitored by the WIMU/i-Walker the system
identifies a possible fall of the user and produces an alarm event.
2. The configured Call centre receives the alarm notification.
3. A Call centre operator tries to contact the patient on the mobile phone, to
check if s/he actually fallen.
4. The patient does not answer to the call.
5. The Call centre sends an ambulance to the patient.
The operator accesses to the IDF Web UI and records that the end user
has not answered.
Extensions
Call center family notification
Sub-Variations
Variation 1
4'. The end user answers to the call.
5'. The end user confirms the fall.
6'. The operator provides first instruction to the end user.
7'. The Call centre sends an ambulance to the end user.
8'. The operator accesses to the IDF Web UI and records that the end user

has fallen.
9'. Call centre family notification.
Variation 2
4''. The end user answers to the call.
5''. The end user communicates that the i-Walker is fallen but s/he is not
fallen.
6''. Call centre family notification.
7''. The operator accesses to the IDF Web UI and records that only the i-
Walker has fallen.
Variation 3
4'''. The end user answers to the call.
5'''. The end user communicates that everything is OK.
6'''. The operator accesses to the IDF Web UI and records that no fall has
occurred.
Variation 4
4*. The end user answers to the call.
5*. The end user communicates s/he didnt fall but need help from a next of
kin.
6*. Call centre family notification.
7*. The operator accesses to the IDF Web UI and records the request of help
and that no fall has occurred.
Variation 5
If no Call centre has been configured
Automatic family notification
Sequence Diagram

Fig. 11: Sequence Diagram
Post Condition
None
Table 2: Fall detection

3.2.2 Call centre family notification
Overview
Title Call centre family notification
Use Case ID UC11
Goal/Purpose The patient expects her/his next of
kin to be notified by the call centre
operator if s/he has fallen down.
Primary Actors and Interfaces Call centre operator
Patients next of kin
Secondary Actors Depending from service
configuration
Initial Status and Preconditions Patients next of kin to notify and the
usage of a Call Centre have been
set
Basic Flow
1. The UI shows to the call centre operator the list of people (patients next of
kin) to notify, depending from the kind of alarm (i.e. users fall, i-Walker10
fall, user request)
2. The Web UI also shows the channel to use for contacting each of them
(e.g. telephone, email, social network) and the protocol to use (e.g. the
order to use in contacting them).
3. The operator tries to contact the list of person according to the configured
protocol (e.g. if s/he does not receive an answer from the first in the list
s/he will try with the successive person in the list and then will try again
with the previous one).
The operator records using the Web UI whom he has been able to contact
and the respective answer.
Extensions
None
Sub-Variations
None
Sequence Diagram

Post Condition
None
Table 3: Call centre family notification

3.2.3 Provision of cognitive training
Overview
Title Provisioning of Cognitive Training
Use Case ID UC12
Goal/Purpose The patient needs to improve his/her
cognitive capabilities to reduce the
risk of falls
Primary Actors and Interfaces End user (patient): IDF end-user
Interface
Clinician: IDF Secondary UI
Secondary Actors None
Initial Status and Preconditions Medical expert has included cognitive
training sessions in patients IDF
training program. Cognitive training
exercises are configured according to
patients current cognitive status.
Service Provisioning Environment Home and Pilot Sites
Time (Duration& Frequency) 2 weekly training sessions of one
hour for 3 months
Basic Flow
1. The user together with the medical expert or clinician goes through the
assigned homework exercises: 5 minutes.
2. The user is reminded of the basics on the use of the surface computer:
5 minutes
3. The Touch screen UI shows to the patient the list of training exercises
to execute according to the configuration.
4. The patient selects an exercise and executes it according to the

instructions of the medical experts.
5. After the patient ended each exercise the score and related information
produced by the Cognitive Training Games are automatically
registered into the patient records.
6. The medical expert reports any other medical observation on the Web
UI.
7. The medical expert indicates on the Web UI that the training is finished.
8. Reported observations are automatically registered into the patient

records.
Extensions
None
Sub-Variations
In case of performing cognitive training at home, only the steps 4 and 5 will
take place.
Sequence Diagram
Fig.13: Sequence Diagram

Post Condition
End user has performed his/her cognitive exercise session.
Table 4: Provisioning of cognitive training

3.2.4 Provision of walking training
Overview
Title Provisioning of walking training
Use Case ID UC13
Goal/Purpose The patient needs to improve his/her
walking capability to reduce the risk
of falls.
Primary Actors and Interfaces End user (patient): IDF end-user
Interface
Clinician: IDF secondary UI
Initial Status and Preconditions It is the time to perform the walking
training as configured (UC4)
Service Provisioning Environment Pilot Sites
Time (Duration& Frequency) 2 weekly training sessions of one
hour for 3 months
Basic Flow
1. The medical expert selects from the Web UI the patient that has to
perform the walking training and starts the training session.
2. The patient performs the walking training using the i-Walker and/or the
AFO that assists her/him during exercises.
3. The medical expert reports any other medical observation on the Web UI.
4. The medical expert indicates on the Web UI that the training is finished.
Data produced by the i-Walker and reported observations are
automatically registered into the patient records.
Extensions
None
Sub-Variations
None
Sequence Diagram

Post Condition
None
Table 5: Provisioning of walking training

3.2.5 Patient assessment and feedback
Overview
Title Patient Feedbacks
Use Case ID UC8
Goal/Purpose The Medical expert wants the
patient to regularly answer to a set
of questions and the answers to be
stored for future consultation.
Primary Actors and Interfaces End User (Patient): IDF End User
Interface
Initial Status and Preconditions A set of questions to submit to the
patient has been configured by the
medical expert
Basic Flow
1. The user ensures the CarePortal is on the cradle and connected to the
power supply. The CarePortal displays the welcome screen and requests
log in. The user enters the agreement number and the CarePortal initiates
a secure connection to the Doc@Home server.
2. The user lifts the CarePortal from the cradle and initiates the questions that
have been pre determined by the clinician.
3. The user answers each question in turn as it is displayed on the CarePortal
screen.
4. The data is encrypted and stored locally on the CarePortal.
5. The user replaces the CarePortal on the cradle when the questions have
been completed.
6. The data is securely transferred to the Doc@Home server.
7. The Clinician views the results on the Doc@Home server over a secure
internet connection.
Extensions
None
Sub-Variations
None
Sequence Diagram

Post Condition
None
Table 6: Patient assessment and feedback

3.2.6 ADL monitoring
Overview
Title ADL monitoring
Use Case ID UC10
Goal/Purpose Store information aboutthe level of
activityduring daily lifefor the
preventionandstudyof the fall.
Primary Actors and Interfaces End user, smartphone, IDF
Secondary User interface
Secondary Actors Researchers
Initial Status and Preconditions Network and devices have been
configured by a technician.
Service Provisioning Environment At home and at pilot site
Time (Duration& Frequency) No temporal restriction in the service
delivery within the autonomy of the
battery systems.
Basic Flow
1. The end userperforms her/his daily activities.

2. Data monitored by the WIMU are used to compute an indicator
related to level of motor activity respectively: High, Medium, Low.
The indicator is visualized on the smartphone screen and
produces an audio message when reaches the High level.
3. Data monitored by the WIMU are sent to the IDF server.
Extensions
If the end user is assisted by the i-Walker during her/his ADL.

4. Data produced by the i-Walker are sent to the IDF server.
Sub-Variations
None
Sequence Diagram

Post Condition
None
Table 7: ADL monitoring

4 CONCLUDING REMARKS
Through the activity of the pilot sites, the IDF integrated platform will aim at
implementing a systematic approach useful to reduce the incidence of falls. The
outcome of this approach to fall prevention will critically depend on the
capability of the IDF platform to exploit the many technologies involved in the
services that are offered. Specifically, products like the i-Walker and the Fall
Detector could well prove to be advantageous in the rehabilitation programmes
designed by the IDF medical team. The outcome of successful rehabilitation or
even occasional training may well contribute to falls prevention, as well as
general rehabilitation using interactive exercises: there is indeed some evidence
that falls can be reduced in people subject to cognitive stimulation. The
capability of the IDF platform to provide quantitative data from FD motion
sensors and proprioceptive/esteroceptive sensors from i-Walker could be
instrumental in capturing patterns of activity of the end users. Secondary IDF
users may find useful these patterns of activity in order to refine their estimates
of the risk of falling, together with data obtained from the UD and the end users
themselves, in response to a series of questions concerning their perception of
the risk of falls managed through CAREPORTAL.
Given this scenario, the fall detection and prevention services of the IDF
platform have been described in this document in their main technical,
functional and operational aspects to ease the subsequent integration work
exposing the main facts enabling the interaction between the disparate
components of the IDF platform.
It is worth noting that the fall detection and prevention services are just a part of
a wider set of services of the IDF platform that include specifically fall
management services, which are available for the secondary IDF users (e.g.,
medical experts, clinicians). The fall management services, which will be
focused in other deliverables, are fundamental for managing the information
collected from IDF services and analyzing the effectiveness of IDF services.
In conclusion, this document represent a pillar on top of which the final IDF
integrated solution can be defined and built. It can also be a practical guide for
the Pilot operators to understand what each single device can offer and how it is
expected to be used practically during its adoption.

REFERENCES
[1] D2.1 End User Selection and Initial Tailoring of Services
[2] D1.3 Pilot Scenarios, Use Case and KPIs
[3] M. Kangas, A. Konttila, P. Lindgren, I. Winblad, and T. Jamsa, "Comparison of
low-complexity fall detection algorithms for body attached accelerometers," Gait
& Posture vol. 28, pp. 285-291, 2008.
[4] D2.1 User Selection and Segmentation SOCIABLE Project (Grant no. 238891)
[5] D3.1 SOCIABLE Services Specification SOCIABLE Project (Grant no. 238891)
[6] D3.2 SOCIABLE Platform Specification SOCIABLE Project (Grant no. 238891)
[7] Basic Use Case Template, Alistair Cockburn, 1996
[8] D1.1 Analysis of Stakeholders Requirements
[9] Annex: Description of the Physical Training Protocol

5 ANNEX I PHYSICAL TRAINING PROTOCOL
5.1 Physical training sessions

Falls occur as a result of a complex interaction of risk factors. The main risk
factors reflect the multitude of health determinants that directly or indirectly
affect well-being. Biological factors due to ageing (such as the decline of
physical, cognitive and affective capacities, and the co-morbidity associated
with chronic illnesses are critical cause of fall) intensifies the risk of falling due
to some environmental hazards. Regular participation in moderate physical
activity is integral to good health and maintaining independence. It prevents
onset of multiple pathologies and functional capacity decline. Moderate physical
activities and exercise also lowers risk of falls and fall-related injuries in older
age through controlling weight as well as contributing to healthy bones,
muscles, and joints (Peel, 2006). Exercise can improve balance, mobility and
reaction time (Gardner, 2000). It can increases bone mineral density of
postmenopausal women and individuals aged 70 years and over.
The American Geriatrics Society (AGS) and British Geriatrics Society (BGS)
(AGS-BGS, 2010) clinical practice guidelines specify that all older adults who
are at risk of falling should be offered an exercise program incorporating
balance, gait, and strength training, such as physical therapy. Flexibility and
endurance training can also be offered, but not as sole components. Because a
large body of evidence supports the recommendation that exercise, in the form
of resistance (strength) training and balance, gait, and coordination training, is
effective in reducing falls, the panel concluded that exercise, in the form of
strength training and balance, gait, and coordination training, should be
included as part of a multifactorial or multicomponent intervention to prevent
falls in older persons and may be considered as a single intervention.
I-DONT-FALL walking training will be directed especially to balance and gait
exercises.
Each training session will be dedicated for 1/2 to balance and 1/2 to gait
exercises after a brief session on warm-up exercises.
- Walking training session of 30:
o 3 of warm-up exercises (exercises selected from warm-up pool)
o 15 of balance (exercises selected from balance pool)
o 15 of gait (exercises selected from gait pool)
- Walking training session of 60:

o 3 of warm-up exercises (exercises selected from warm-up pool)
o 5 pause

Below, a list of exercises for each physical function.
PHYSICAL FUNCTION EXERCISE

Warm-up pool
Stretching
Squat with spread legs
Squat with spread legs in anteroposterior
Balance pool
Lift up heels
Lift up tiptoes
Lift up heels/tiptoes
Lateral load shift
Lateral load shift with contralateral leg flexion
and torso rotation
Forward load shift
Hip lift up opposite the support leg
Load holding for 10 seconds
Load holding with heel lift up
Leg flexion / alternate leg flexion
Leg flexion and extension / alternate leg
flexion and extension
Leg flexion and extension backwards
Foot sliding forth and back
Gait pool
Moving walker forward
Moving walker forward oblique
Moving walker forward flexing torso
Moving walker forward oblique flexing torso
Load shift with arms
Load shift with arms and kick
Move walker forward / backward
Move walker forward / backward in line

Move walker forward / backward marching
Move walker on a wide curve
Move walker on a curve marching in place
GAMES DESCRIPTION
For each exercise has been realized a specific video; to se the video use this
link:
http://dl.dropbox.com/u/45129956/IDF%20Training%20Videos/D2.2%20-
%20Exercises%20Videos.zip
BEFORE STARTING EXERCISES

Set the handles at the greater trochanter height STILL EX 00
WARM-UP EXERCISES
Stretching
(Duration: 1 min) VIDEO EX 28
Hands on the walker handles

Flex right leg 30
Extend left leg backwards
Shoulders slightly forward
Repeat exercise for 30 seconds

Repeat also with left leg
Squat with spread legs


Spread legs shoulder-width
Slowly flex legs, holding the back erect and soles on the ground
Hold position for 1 sec.

Extend legs
Repeat exercise 8 times
Points of attention
At patient improvement increase exercise difficulty:
- Increase speed
- Increase repetition
- Increase holding position
- Execute with one hand on walker handles
Squat with spread legs in anteroposterior


Move right leg at about 10 cm in front of left leg
Slowly flex legs, holding the back erect and soles on the ground
Hold position for 1 sec.
Extend legs

Repeat also with left leg in front
Points of attention
- Increase speed
BALANCE EXERCISES
(all exercises are in increasing order of difficulty)
Lift up heels
(Duration: 1 min) VIDEO EX 01-02-03

Closed legs
Lift both heels and hold position for 1 sec.
Back on support heels
Repeat exercise 8 to 15 times
Points of attention
- Execute with eyes closed
- Hold heels longer
Lift up tiptoes

Closed legs
Lift both tiptoes and hold position for 1 sec.
Back on support toes
Points of attention
- Hold tiptoes longer
Lift up heels/tiptoes

Closed legs
Lift both heels and hold position for 1 sec.
Back on support heels
Lift both tiptoes and hold position for 1 sec.
Back on support toes

Points of attention
- Hold heels longer
Lateral load shift


Slowly shift the load on right leg and stay
Slowly take hips back to centre
Slowly shift the load on left leg and stay

Points of attention
- Increase speed



Slowly shift the load on right leg, flex left leg at the same time (lifting or not the
heel) and stay
Slowly shift the load on left leg, flex right leg at the same time (lifting or not the
heel) and stay

Points of attention
- Increase speed
Lateral load shift with contralateral leg flexion and torso rotation

heel), rotate torso and head on loaded leg side and stay
Slowly shift the load on left leg, flex right leg at the same time (lifting or not the
heel), rotate torso and head on loaded leg side and stay

Points of attention
- Increase speed
Forward load shift


Move right leg at about 20 cm in front of left leg
heel) and stay
Slowly go back to start position

Points of attention
- Increase speed
Hip lift up opposite the support leg


Lift up right hip flexing right foot
Maintain back erect
Back to start position

Repeat also with left hip
Points of attention
Load holding for 10 seconds

(Duration: 30 sec) VIDEO EX 11

Closed legs
Lift and flex right leg at about 30 cm from the ground
Hold balance position on left leg for 10 sec.

Points of attention
Load holding with heel lift up


Closed legs
Lift and flex right leg at about 30 cm from the ground
Lift left heel and hold
Back on support heel

Points of attention
Leg flexion / alternate leg flexion


Closed legs

Lift and flex right leg at about 90
Maintain back erect

Points of attention
Leg flexion and extension / alternate leg flexion and extension


Closed legs
Maintain back erect
Extend leg

Points of attention
Leg flexion and extension backwards


Closed legs

Maintain back erect
Extend leg backwards

Points of attention
Foot sliding forth and back


Move right foot forth and back, sliding near ground
Maintain back erect
Extend leg backwards

Points of attention
GAIT EXERCISES
(all exercises are in increasing order of difficulty)
Moving walker forward


Flexed arms with elbows near body
Extend both arms, moving the walker forward

Points of attention
Moving walker forward oblique


Extend both arms, moving the walker right in oblique direction
Extend both arms, moving the walker left in oblique direction

Points of attention
Moving walker forward flexing torso


Extend both arms, moving the walker forward and flexing torso

Points of attention
Moving walker forward oblique flexing torso


Extend both arms, moving the walker right in oblique direction
and flexing torso
Extend both arms, moving the walker left in oblique direction
and flexing torso

Points of attention
Load shift with arms


Step forward with right leg and move the walker
Flex left foot leaving toes on the ground

Points of attention

- Increase speed
Load shift with arms and kick


Step forward with right leg and move the walker
Extend left leg forward

Points of attention
- Increase speed
Move walker forward / backward


Step forward moving the walker
Maintain back erect
Repeat exercise for 1 minute

Repeat also backwards
Points of attention
- Increase speed

Move walker forward / backward in line

Keep feet walking on an imaginary straight line
Maintain back erect

Points of attention
- Increase speed
Move walker forward / backward marching


Flex legs 60
Maintain back erect

Points of attention
- Increase speed
Move walker on a wide curve


Make a wide curve on the right
Continue moving in a wide circle
Maintain back erect

Repeat making a left curve
Points of attention
- Increase speed
Move walker on a curve marching in place


Step in place flexing legs 60
Turn right with the walker
Maintain back erect
Repeat exercise for 1 turn

Repeat turning left
Points of attention
- Increase speed
References
Peel NM, McClure RJ, Hendrikz JK (2006). Health-protective behaviours and
risk of fall-related hip fractures: a population-based case-control study. Age
Ageing, 35(5):491-497.

Gardner MM, Robertson MG, Campbell AJ (2000). Exercise in preventing falls
and fall related injuries in older people: A review of randomised controlled trials.
British Journal of Sports Medicine, 34:7-17.
American Geriatrics Society, British Geriatrics Society. Clinical practice
guidelines: prevention of falls in older persons. New York, NY: American
Geriatrics Society; 2010.
http://www.americangeriatrics.org/health_care_professionals/clinical_practice/cli
nical_guidelines_recommendations/2010/. Accessed June 22, 2010.

6 ANNEX II COGNITIVE TRAINING PROTOCOL
6.1 Cognitive training exercises.

Cognitive dysfunction is associated with falls (Tinetti et al., 1988), in fact older
adults with cognitive impairment show an odd of falling which is 5 times greater
than older adults without cognitive impairment.
In particular, patients with executive functions deficit are more likely to act in
ways that could result in a fall (Rapport et al., 1998) and he safe ambulation in
older adults may involve executive function (Yogev-Seligmann et al., 2008).
Thus, the treatment of executive functions may reduce fall risk (Mirelman et al.,
2012).
Given the positive and effective experience in SOCIABLE (CIP Pilot action -
SOCIABLE Motivating platform for elderly networking, mental reinforcement and
social interaction No: 238891), it has been decided to replicate a set of exercise
already operated there and that perfectly fit with the purpose of IDF. Some
exercises has been specifically created to complain to the IDF needs.
I-DONT-FALL cognitive training will be directed especially to: executive
functions and attention which is considered as a specific example of executive
function.
Other cognitive abilities will also be trained such as
memory
language
orientation
visuospatial abilities
reasoning
Each training session that will comprehend cognitive training will be dedicated
for 2/3 to executive functions and attention exercises and 1/3 to other cognitive
functions.
- Cognitive training session of 30:

o 20 of executive functions and attention (exercises selected from
executive functions and attention pool)
o 10 of other cognitive functions (exercises selected from memory,
language, abstract reasoning, visuo spatial ability, spatial
orientation pool)
- Cognitive training session of 60:

o 40 of executive functions and attention (exercises selected from
executive functions and attention pool)

o 20 of other cognitive functions (exercises selected from memory,
language, abstract reasoning, visuo spatial ability, spatial
orientation pool)
During each part of the training medical expert will choose games to trained the
selected function (pool) according with preferences of patients (to improve
motivation) and trying also to vary the training.
Below, a list of exercises for each cognitive function.
COGNITIVE FUNCTION EXERCISE

executive functions pool
Picture sort
Similarity
Differences
Take away menu
Analogies
N back
Remember the sequence
Walking on the stones
Remember the colour
attention pool
Lost in the city
Guess who
memory pool
Hide and find
Remember your order
Remember the drawing
Find the pairs
Who belongs where
Remember the picture
abstract reasoning pool
Incomplete grids
visuospatial abilities pool

Copy the figures
Puzzle
language pool
Synonyms
Antonyms
spatial orientation pool
Travelling in Europe
My home
Difficulty level
Each game will start with the easiest level and the level difficulty will be
increased after two sessions at the top level.
GAMES DESCRIPTION
EXECUTIVE FUNCTIONS
Picture sort
There are two boxes of different colour. The images are presented one by one
on top of the screen and the user has to drag and drop each image to the
correct box by discovering the hidden rule.
Instructions
When you moved in your friends house photo boxes opened, the box labels
were gone and the photos mixed up. Try to sort them out by putting photos in
the correct photo box. Pay attention your friend has shared the photos with a
hidden rule. Drag photos that follow the rule in the green box and photos that
dont follow the rule in the red box.
Difficulty levels
Difficulty level 1: In the case of difficulty level 1, the difference between
the pictures is obvious.
Difficulty level 2: In this case we have subcategories (fruits vs. things that
are foods but not fruit such as chicken, potato, but also different things
such as car, airplane etc).

Difficulty level 3: In this case, it is more difficult to find the differences
between the images. Photos that dont follow the rule have some similar
feature. Moreover the images are more elaborate.
Similarity
The user is presented with a couple of words/pictures; he has to explain in what
way they are alike. The computer presents the options and the user has to
choose the answer selecting with his finger.
Instruction
You have to help your nephew to do homework. On the screen it will appear a
pair of word/figure. Your nephew has to figure out in what way these things are
alike. Help him choosing the answer with your finger that best describe the
similarity. Pay attention some other answer could be right but you have to
choose the answer that best describe both things.
Difficulty level:
Difficulty level 1:
Banana -Orange? Options: Fruits, are both round, grow in the
same season
Boat-Car? Options: Transport, have the engine, need water to
work
Difficulty level 2:
Air - Water? Options: Are necessary to live, are liquid, the air we
breathe and the water we drink.
Poetry - Statue? Options: Are art, a portry describe a statue, read
a poetry and see a statue.
Difficulty level 3:
Praise-Punishment? Options: Educational techniques, are both
admiration, they cancel each other out.

Earthquakestorm? Options: Atmospheric phenomenon, occur
together, cause always destruction.
Differences
The user is presented with a couple of words/pictures; he has to explain in what
way they are different. The computer shows the options and the user has to
choose the answer selecting with his finger.
Instruction
You have to help your nephew to do homework. On the screen it will appear a
pair of word/figure. Your nephew has to figure out in what way these things are
different. Help him choosing the answer with your finger that best describe the
difference between the pair of word/figure. Pay attention some other answer
could be right but you have to choose the answer that best describe differences.
Difficulty level
Difficulty level 1:
Sugar honey: are sweet/ Honey is natural, sugar must be
processed/ are liquid.
Difficulty level 2:
Astronomy astrology: Astronomy is the study of the universe,
astrology is the study of positions of stars and planets/ astrology
is a part of astronomy/ astronomy is the study of planets, astrology is
the study of stars.
Difficulty level 3:
Liemisunderstanding: Lie is intentional, misunderstanding is
unintentional/both are false interpretation/ are synonymous.
Take away menu

The aim of the game, consist of composing a menu based in previous rules.

Instruction
You are on holiday in a hotel with your family. In order to offer you the best and
quickest service you are kindly invited to compose your menu for the dinner.
Choose your dishes from our Chef's list of the day!
Difficulty levels
The difficulties that can be selected are: the number of guests, the number of
dishes, number of criteria for selecting, in particular:
Difficulty level 1: the user has to select 4 dishes (hors-d'oeuvre, first
course, main course, side dishes/vegetables, dessert etc). In this level
we have 1 criteria for selecting the dishes (for example dont have
mushroom or meat, shouldnt spend more than etc., cold dish etc). The
Chefs list have 3 dishes for each type of food.
Difficulty level 2: the user has to select 4 dishes. In this level the user has
to order also for another guest and with 2 criteria (1 criteria for each
person). The Chefs list have 4 dishes for each type of food.
Difficulty level 3: the user has to select 4 dishes. In this level the user has
to order also for another guest with 2 criteria (1 criteria for each person).
The Chefs list have 5 dishes for each type of food.
Analogies
Analogies provide excellent training in seeing relationships between concepts.
In analogies, the user is given one pair of related words/pictures and another
word/picture without its pair. The user must choose a word/picture that has the
same relationship to the word/picture as the first pair. For example, fire is to hot,
as ice is to cold. Pairs of words/picture can be related in many ways, including
the following types: opposites, synonyms, things that go together (bow/arrow),
object and classification (green/color), object and related object (dog/puppy),
object and function (pen/write), problem and solution (tired/sleep), degrees of a
characteristic (cold/freezing) etc.
Difficulty levels
The difficulty levels will be determined on the basis of the abstraction level and
the frequency/familiarity of the stimuli (which could be words, pictures or even
sounds). Three difficulty levels are envisaged:
Difficulty level 1
Verbal analogies
1. Car: road train:______________________
track vehicle fast wheel
Picture analogies

1. Leopard: spots zebra: ______________________
cow skin rabbit fur zebra skin feathers
Difficulty level 2
Verbal analogies
1. Fish: egg plant: ______________________
leaf root seed stem
Picture analogies
1. Fish: submarine bird: ______________________
kite airplane cloud birdcage
Difficulty level 3
Verbal analogies
1. Violence: activity melancholy: ______________________
evening cruelty mood silence
N back
This exercise is in progress as part of the IDF project.
The user is presented with a sequence of pictures (Figure 1). The user is asked
to press the picture when a pictures matches with a picture presented n steps
earlier in the sequence (e.g. 1, 2 or 3). By side, a green flag or a red X appear
whether the answer is right or wrong.
Figure 1

at this point the subject has to press on the X in the 1-back condition
Press the picture each time the current picture that you see matches the one
from n steps earlier in the sequence.
Difficulty levels
The difficulty level is determined by the number of steps:
Remember the sequence

The user is presented with an array (Fig 1) with a start box coloured. All
possible pictures that can be displaced on the array are presented at the bottom
of the array. The sequence starts with one picture positioned in one box next to
the start box. Then the clear array is re-presented and the user has to drag the
correct picture into the correct position. Then two other pictures are presented
each time in a different sequence and so on. (Fig 2).
The game waits for the user to position the sequence that were presented in
order to continue the game. The user is notified upon making a mistake. The
user takes as much time as needed to complete each color sequence.
Figure 1

Instructions
The pictures are positioned in the array each time in a different sequence. Try
to remember the pictures in their right sequence!
Difficulty levels
The difficulty level is determined by the maximum number of pictures positioned
every time.
Walking on the stones

The user is presented with a ground with some stones (Fig 1). The stones could
be disposed in a geometrical array (Fig 1A) or not (Fig 1B). The stones get
coloured (one by one/in sequence). Initially one stone is coloured, then two,
three, etc... each time in a different sequence. The user has to press on the
same stones after the sequence has been presented (Fig 2).
The game waits for the user to press the sequence that were colored in order to
continue the game. The user is notified upon making a mistake. The user takes
as much time as needed to complete each color sequence.
Figure 1
A B
Figure 2

Instructions
The stones get colored each time in a different sequence. Try to walk only on
the stones that were colored in the right sequence!
Difficulty levels
The difficulty level is determined by the maximum number of stones colored
every time:
If the user makes one or more errors the sequence is not incremented in the
following step. After 3 repetitions the sequence is reduced by one step. In this
way the level of difficulty is tailored on the subject capacity.
Remember the colour

The user is presented with a multicolored pie. The pie keys/buttons get
illuminated (one by one/in sequence). Initially one color is illuminated then two
then 3, etc. Each time the whole sequence is illuminated. For example, Red
Green Blue Yellow gets illuminated in this specific sequence. Afterwards,
the user has to remember in which specific sequence the pie keys/buttons were
illuminated. The game wait for the user to press the pie keys/buttons that were
illuminated in order to continue the game. The user is notified upon making a
mistake and then the game starts from the beginning. It would be nice to have a
press effect on the keys. The user takes as much time as needed to complete
each color sequence.
Remember the color 1

Instructions
The colored pie pieces illuminate each time in a different sequence. Try to press
the pie keys/buttons that were illuminated in the right sequence!
Difficulty levels
The difficulty level is determined by the number of colors illuminated every time,
the speed of the alternation of the pie keys/buttons (very slow slow
medium).
ATTENTION
Lost in the city

The user is presented a group of persons on the screen moving in different
directions. The aim of the game consists of choose the direction of the central
person suppressing automatic response to the stimuli.
Instruction
A groups of persons will appear one at time on the screen . Touch with your
finger on the arrow that corresponds to direction of the central person.
Three difficulty levels are determined on the basis of the number of distractors,
namely:
Difficulty level 1: 5 persons in total, all showing to the same direction
except for the person in the middle.
Difficulty level 2: 5 persons in total, 3 of them showing to one direction, 1
showing to another and the person in the middle showing to a different
direction from all the others.
Difficulty level 3: 5 persons in total, 2 of them showing to one direction
(e.g. up), 2 of them showing to two different directions (left and right
respectively) and the person in the middle showing to a different direction
from all the others (e.g. down).
Guess who
The aim of the game consists of trying to eliminate candidates and correctly
guess the mystery person chosen using the cues provided.
Instructions
Youll be presented with images of 10/15/20 different people. Based on the cues
provided, try to eliminate candidates and correctly guess the mystery person
chosen! Time matters, so be as fast as you can!

Difficulty levels
Difficulty level 1: The user is presented with the images of 10 people and
is given clues only on obvious outward appearance characteristics of the
person selected.
is given clues both on outward appearance and personality/personal
history of the character selected.
is given clues both on outward appearance and personality/personal
history of the character selected.
MEMORY
Hide and find

The user is shown of a fully-furnished and fully-decorated room and is asked to
hide 5-10 items in there. After a 15-20 minute delay, the user is asked to recall
where he has hidden the various objects.
Difficulty levels
Difficulty level 1. The user is asked to hide 5 items: car keys, wallet, glasses,
TV remote control and pills.
Difficulty level 2. The user is asked to hide 7 items: car keys, wallet, glasses,
TV remote control, pills, identity card and camera.
Difficulty level 3. The user is asked to hide 10 items: car keys, wallet,
glasses, TV remote control, pills, identity card, camera, watch, umbrella and
mobile phone.
Remember your order

The aim of the game consists of trying to remember the order from a list.
Instruction
The hotel has lost your order. Try to remember it from this list. Choose your
dishes by dragging them from the menu your order! Try to be as fast.
Difficulties levels
Difficulty level 1: the user is presented with 8 dishes
Difficulty level 2: the user is presented with 12 dishes
Difficulty level 3: the user is presented with 16 dishes.
Remember the drawing

The designs presented arent created by random lines. Then, the user is asked
to reproduce the design (and erase lines, if necessary) using his finger.
Instruction
You will be presented with a design created on a 9-dot grid. Look at it carefully
and try to memorize it. When the design disappears, try to reproduce it on the
empty grid.
Difficulty levels
Difficulty level 1: The design is comprised by two non-overlapping
elements
Difficulty level 2: The design is comprised by three non-overlapping
elements.
Difficulty level 3: The design is comprised by three elements of different
colors. In this case, the user will select the appropriate colour from a
small palette (red, green, blue, black)
Find the pairs
The aim of the game, consist of finding the pairs matching images.
Instructions
The user has to find the pairs that match the images. Cards are randomly dealt
with the picture side down. Flip over any two cards by tapping on them. If the
pictures on the cards are identical they will disappear. If they are not identical
they will be flipped back picture side down.
At the start of the game the images have to show to the patient one by one and
called. Then the images have to face down and placed on a grid
Difficulty levels
Difficulty level 1: 8 cards (4 pairs)
Who belongs where

The aim of the game, is to identify the pictures and categorize them choosing
between the categories available. After, the user has to put the picture in the
category-box, drag and drop it into the box identify
Remember the picture

The game is presented with a photo album of one large and several smaller
photos. The largest photo the one to remember is replaced with another one
after a few seconds. Among the smaller photos is the one that was shown
previously and needs to be chosen from. The user is given time to press the
correct photo/button in order to continue the game. The user is notified when
making a mistake and then the game starts from the beginning. It would be nice
to have a press effect on the photos. The user takes as time as needed to
make a choice and the game continues in that manner.
Instructions
The photo album illustrates a large photo which is quickly replaced with another
one. Try to select the original photo among the smaller ones!
Difficulty levels
The difficulty level is determined by the number of the photos illustrated every
time, the time the photo to remember stays on screen (very short short
medium), the complexity of the photos and the similarities between them.
ABSTRACT REASONING
Incomplete grids
The aim of the game is to complete the design show it. The user has to choose
the correct figure that best completes the pattern.
VISUOSPATIAL ABILITIES
Copy the figures

The aim of the game is to copy the figure presented. The user has to try to
reproduce it using the fingers.
Puzzle
The user is shown pieces of a puzzle and is asked to put them onto the grid as fast as he
can in order to make the picture. There is no time limit to complete the game, but the
user gets a time bonus if he/she puts the puzzle together quickly enough.
Difficulty levels
Difficulty level 1. Puzzles with 9 pieces
LANGUAGE
Synonyms and Antonyms

The games Synonyms and Antonyms are presented together as the games
design will be exactly the same. In the case of these two games, the words are
presented in two different lists. The user is required to draw a line with his finger
between the words on the left and their synonyms/antonyms on the right.
Difficulty levels
Difficulty level 1: list of 10 simple, concrete, everyday words
Difficulty level 2: list of 15 both concrete/frequently used and abstract/less
frequently used words
Difficulty level 3: list of 15 more difficult/abstract/less frequently used words.
SPATIAL ORIENTATION
Travelling in Europe
The user is presented with a map of Europe. Each country is clearly
recognizable: different colour, name and a landmark easily identifiable (e.g.
Eiffel tower for Paris). On this map the route that is going to be followed is
presented.
The aim is to remember:

the countries to be visited
the order in which they will be visited.
Then the route disappears and the user has to:

point with his finger the countries that have been chosen (in random order)
draw with his finger the route from one country to the other.
Instruction
You decided with your friend to have a trip in Europe next summer. Your friends
have already planned the tour and show you the map with the countries to visit.
When the route disappears try to remember the countries you well visit and the
route to follow! At the beginning point with your finger the country chosen and
then mark the route with your finger how your friend showed.
Difficulty level
Difficulty level 1: The tour comprises 3 countries.
Difficulty level 2: The tour comprises 5 countries.
Difficulty level 3: The route comprises 7 countries.
My home
For the purposes of this orientation game, the user has to find his way in his
new home. A person standing in the center of a red circle in placed on the
starting point. A different indication is used to show the room where the user
must go.
Instructions
You have just moved in your new house. Try to familiarize with it by going from
one room to another as fast as you can! Use your finger to draw your route,
without bumping into the furniture.
Difficulty levels
The difficulty levels are determined on the basis of the number of rooms,
furniture and decorative items.
Difficulty level 1: Five rooms. Bedroom, kitchen, living room, wc, garden.
Few furniture and decorative items.
Difficulty level 2: Seven rooms. Bedroom, office, kitchen, living room, play
room, wc, garden. More furniture and decorative items.
Difficulty level 3: Nine rooms. Master bedroom, kids bedroom, kitchen,
living room, play room, office, wc, gym, garden. Many furniture and
decorative items.
References
Tinetti ME, Speechley M, Ginter SF. Risk factors for falls among elderly persons
living in the community. N Engl J Med. 1988;319:17011707.
Rapport LJ, Hanks RA, Millis SR, et al. Executive functioning and predictors of
falls in the rehabilitation setting. Arch Phys Med Rehabil. 1998;79:629633.
Yogev-Seligmann G, Hausdorff JM, Giladi N (2008) The role of executive
function and attention in gait. Mov Disord 23: 32942.
Mirelman A, Herman T, Brozgo M, Dorfman M, Sprecher E, Schweiger A, Giladi
N, Hausdorff JM. (2012). Executive Function and Falls in Older Adults: New
Findings from a Five-Year Prospective Study Link Fall Risk to Cognition.
PlosOne, 7 (6), 1-8.
7 ANNEX III PLACEBO TRAINING PROTOCOL
Randomized controlled trials are experimental study designs in which
individuals are randomly assigned to a treatment group or a control group (e.g.,
placebo, standard therapy, or other treatment). Randomized controlled trials are
the most accepted scientific method of determining the benefit of a therapeutic
procedure and represent the best available evidence for this intervention and
condition.
In literature (Mosby, 2005) one of the possible definition of placebo group is: n
a group of persons that serves as a baseline for comparison for assessment of
the effects of a particular intervention. While persons in the treatment group
receive the experimental treatment being studied, the attention placebo control
group receives a treatment that mimics the amount of time and attention
received by the treatment group but is thought not to have a specific effect upon
the subjects.
By comparing peoples responses to the placebo and to the treatment being
tested, researchers can tell whether the treatment is having any real benefit,
rather than patients simply feeling better because something is being done.
In order to better understand placebo effects, in non-randomized or uncontrolled
trials, where there isnt a control group, results can have a potential bias. For
instance, one study design commonly used in the cognitive rehabilitation
therapy literature is the single-group before and after (pre-post) design. In
studies that employ this design, a group of individuals are tested on an outcome
of interest before receiving the intervention and then are retested on that
outcome after receiving the intervention. The pre-post assessment of the
outcome is intended to measure any change or improvement that results from
receiving the intervention.
However, a number of alternative factors may also explain changes observed in
this type of study. These factors include spontaneous recovery (e.g.,
improvements in cognitive functioning that may occur without therapy that
specifically targets cognitive problems); testing effects (i.e., practice effects of
taking a pre-test and then taking it again as the post-test); and placebo effects
(i.e., improvements that may result from individualized attention received by
patients in a study, regardless of the specific intervention). Thus, randomized
controlled trials were considered the most appropriate source of evidence for
the questions posed in this report because they allow researchers, clinicians,
and the public, including patients and their lay caregivers, to distinguish
between the effectiveness of cognitive rehabilitation therapy and other factors
that might lead to false conclusions about whether the therapy is actually
working.
Moreover patients beliefs and expectancies are critically important for the
effects of placebo and need to be carefully considered in the rehabilitative field,
especially due to the intensive interaction between the rehabilitation team, the
patients and their families.
It is already known that not all placebo interventions will have the same effects
(Vickers AJ 2000). Evidence exists that sham devices and procedures have
enhanced placebo effects compared to placebo pills (Kaptchuk TJ 2000). For
example, a RCT prospectively compared the two different placebo controls- a
sham device (a validated sham acupuncture needle) and an oral placebo pill
and found that the sham device reduced pain significantly more than an inert pill
(1. Kaptchuk TJ 2006). Elaborate rituals can produce effects that are greater
than simple pill ingestion. Furthermore, the accompanying efforts of
participation (for instance - procedures such as laser therapy) are much more
evocative and potentially potent than medication. Whether assigned to a
genuine or dummy treatment, patients have to make a commitment to travel
and therefore do the potentially valuable exercise for just getting to the
treatment. Transportation often requires the assistance of family and friends
that can provide tacit social support. In a trial, these factors, which will
accounted as non-specific, are all likely to increase the effect size of the
placebo arm and show a difference from the genuine treatment which is more
difficult to detect.
Patients and practitioners often need to negotiate and reach mutual agreement
on how to cooperate and work together in a manner far more complex than
what is required to take medications. These interactions often require
explanations, assurances, opportunities for dialogue and a high degree of trust.
Such genuine patient-physicians encounters, necessary in both the genuine
and placebo arms, have demonstrated their ability contribution to positive health
outcomes (Di Blasi 2001). For example, a recent RCT demonstrated that
augmenting the patient-practitioner with a patient-centered approach in sham
acupuncture treatment can significantly enhance clinical outcomes compared to
sham acupuncture performed in a business-like disease-centered clinical
encounter (Kaptchuk TJ 2008).
7.1 Placebo training exercises.

In IDF partecipants will be assigned to experimetal groups or to a control group
following a randomization scheme. The control group will be submitted to a
treatment lasting the same number of hours as the experimental treatment.
In particular during the session they will be exposed to some computerized
tasks assumed not have any therapeutic effects such as for instance filling a
database with easy verbal material on the same platform of cognitive games.
As above mentioned in such way we want to eliminate potential confounding
factors that could affect the results.
References
Mosby's Dictionary of Complementary and Alternative Medicine. (c) 2005,
Elsevier
Vickers AJ, de Craen AJ. Why use placebos in clinical trials? A narrative review
of the methodological literature. J Clin Epidemiol. 2000;53:15761.
Kaptchuk TJ, Goldman P, Stone DA, et al. Do medical devices have enhanced
placebo effects? J Clin Epidemio. 2000;53:78692.
Kaptchuk TJ, Stason WB, Davis RB. Sham device v inert pill: randomised
controlled trial of two placebo treatments. BMJ. 2006;332:3917.
Di Blasi Z, Harkness E, Ernst E, et al. Influence of context effects on health

outcomes: a systematic review. Lancet. 2001;357:75762.
Kaptchuk TJ, Kelley JM, Conboy LA, et al. Components of the placebo effect:
randomized controlled trial in patients with irritable bowel syndrome. BMJ.
2008;336:9981003.

Fall Detection-Prevention Functionalities and Operative Protocols

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fall Detection-Prevention Functionalities and Operative Protocols

Uploaded by

Copyright:

Available Formats

CIP-297225

Angelo Maria Sabatini

Due date of deliverable: 15/02/2013

Resubmission date: 15/02/2013

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 1 of 111

0.1.1 08/08/2012 Draft S. Rizou (SiLo) Comments on the

0.1.2 10/08/2012 Draft V. Genovese (SSSA) New index of the

0.1.3 28/08/2012 Draft V. Genovese (SSSA) First draft that includes

0.1.4 06/09/2012 Draft C. Zaccarelli (ASL) Draft that includes the

0.1.6 14/09/2012 Draft M. Melideo (ENG) Comments on the new

0.1.7 17/09/2012 Draft P. Levene (DOCOBO) Draft that includes the

0.1.8 19/09/2012 Draft A.M. Sabatini (SSSA) The Introduction is

0.1.9 20/09/2012 Draft S. Rizou (SiLo) Draft that includes the

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 2 of 111

0.1.11 23/09/2012 K. Giokas (SiLo) Comments on the

0.1.12 26/09/2012 Draft P. Levene (DOCOBO) Version with additional

0.1.13 30/09/2012 Draft A.M. Sabatini (SSSA) Version revised on the

1.1.0 02/10/2012 Draft A.M. Sabatini (SSSA) Version submitted to the

1.1.1 08/10/2012 Draft A.M. Sabatini (SSSA) Version revised on the

1.1.2 12/10/2012 Draft M. Melideo (ENG) Further comments and

1.1.3 13/10/2012 Draft A.M. Sabatini (SSSA) Version revised on the

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 3 of 111

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 4 of 111

CIP Project 297225 Acronym I-DONT-FALL

Deliverable Number D2.2 Title I-DONT-FALL Fall Detection/Prevention Functionalities

Work package Number 2 Title Service Definitions and Pilot Specifications

Date of delivery Contractual 15/02/2013 Actual 15/02/2013

Authors (Partner) Angelo Maria Sabatini, Vincenzo Genovese

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 5 of 111

EXECUTIVE SUMMARY ........................................................................................... 4

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 6 of 111

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 7 of 111

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 8 of 111

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 9 of 111

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 10 of 111

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 11 of 111

Goal Describe in this section the goal of the tool/service

Target population Describe the target population of the tool/service

Functional view Describe the functionalities ofthe tool/service. Present

Hardware Describe in this subsection the hardware used for

Software Describe in this subsection the software used for

Communications Describe in this subsection the communication

User Interfaces Describe in this subsection the user interface of the

Environmental Describe in this subsection the environmental

User/Physical Describe in this subsection the user/physical

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 12 of 111

2.1.2 Target Population

2.1.3 Functional View

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 13 of 111

2.1.4 Technical View

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 14 of 111

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 15 of 111

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 16 of 111

iv) User Interfaces

Fig. 1: Screenshot of the IDF FD UI.

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 17 of 111

vi) User/Physical Requirements

2.2 The i-Walker functions and services

Fig. 2: The i-Walker.

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 18 of 111

2.2.4 Technical View

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 19 of 111

iii) Communications Integration

I-DONT-FALL 297225 D2.2 Version 1.2, dated 14/10/2012 Page 20 of 111