Proposal and Validation of a Domaine Specific Language for the
Representation of the AGGIR Constants
Jos
´
e Manuel Negrete Ram
´
ırez
1
, Philippe Roose
1
, Marc Dalmau
1
and Michel Bakni
2
1
Universit
´
e de Pau et des Pays de l’Adour, IUT de Bayonne - LIUPPA, Anglet, 64600, France
2
Universit
´
e de Technologie Belfort-Montb
´
eliard, Belfort cedex, 90010, France
Keywords:
Domain Specific Language, Feature-oriented Programming, Pervasive Computing.
Abstract:
In this paper, we propose a Domain Specific Language (DSL), and we focus on the AGGIR (Autonomie
Grontologie Groupes Iso-Ressources) grid model, in order to exploit the variety of interaction capabilities ac-
cording to the performanceto current activities, users, and context over the time domain. Our aim is providing
an analyis tool regarding the coherent behaviour of elderly/handicapped people within a home environment
by means of data recovered from sensors using the iCASA simulator. For the DSL validation, we particularly
focus on three of the AGGIR variables: dressing, hygiene and transfers; by evaluating their testbility in many
scenarios, especially the abnormal ones, which contain readings representing the occurrence of accidents or
unexpected behavior of the elderly, in order to see the ability of the system to understand the obtained records
correctly and thus generate the appropriate event information.
1 INTRODUCTION
Due to the increase of aging population and the ne-
cessity to avoid expensive hospital-based health care
(Zhang et al., 2005) for this sector, reducing medical
costs and improving quality of care service (Varshney,
2003) have become in recent years a need for new care
delivery mechanisms ans structures (Boulos et al.,
2009).
The present article aims to achieve the monitoring
of a person within a smart home environment to verify
and to detect possible anomalies related to his cohe-
rent behaviour. To achieve such a goal, we will iden-
tify the activities performed by the inhabitants over
a certain period of time, by means of collection and
analysis of data obtained from sensors located in the
sourroundings of the aforementioned environment.
In order to address such a task, we define a Dom-
ain Specific Language (DSL) which will permit to
perform the analysis of the collected data.
Moreover, this DSL will be able to recognise a
categorisation of activities based on the constants of
the AGGIR (Autonomie Gerontologie Groupes Iso-
Ressources) grid (Vetel, 1994), (which classifies au-
tonomy levels to various environmental factors af-
fecting a the activities and social life of a person).
AGGIR is currently the legal tool in France for me-
asuring the autonomy of the elderly.
The main objective of this paper is to present a
DSL which will allow to express these constants and
the activities composing the AGGIR grid. For this
matter, we intend to use a representation in the form
of a plot, which will help providing a history for de-
tecting abnormal behavior of the inhabitants.
A validation will also be considered. Three con-
stants from the AGGIR grid (transfer, hygiene and
dressing) will be represented. In our validating sce-
nario, we collect information from sensors located
within a simulated environment with the aid of iCasa
(Lalanda et al., 2014), by means of a data file returned
by a simulation run from this tool, such as location of
the inhabitant(s), date and time, among others.
2 STATE OF THE ART
The development of an intelligent indoor environment
that is both context-aware and interactive is the main
goal of research. In this regard, we present the ba-
sis on which this paper is based; this includes a me-
chanism for classifying wireless sensors. In addition,
an introduction of a standard, locally developed in
France, to calculate the level of autonomy is intro-
duced.
The work of Li et al. (Li et al., 2016), suggests a
classification of smart houses. According to this clas-
438
Ramírez, J., Roose, P., Dalmau, M. and Bakni, M.
Proposal and Validation of a Domaine Specific Language for the Representation of the AGGIR Constants.
DOI: 10.5220/0006590604380445
In Proceedings of the 11th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2018) - Volume 5: HEALTHINF, pages 438-445
ISBN: 978-989-758-281-3
Copyright © 2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
sification, three generations of home automation have
already existed, the first generation depends on wi-
reless technology and a proxy server approach. The
introduction of artificial intelligence marks the start
of the second generation, a totally new context-aware
environment was achieved. The current generation is
the third one, it can be distinguished by its interacti-
vity, the environment both understands and interacts
with the needs of the user.
The work of Liau et al. (Liau et al., 2008) stu-
dies Home Automation System (HAS), although it
concentrates on developing a tracking indoor system,
it shows the importance of using a grid of sensors
and controllable actuators in order to create active
context-aware services.
Despite significant progress in this domain, the
absence of a standard wireless sensor categorisation
is a major problem; as stated by Arora et al. (Arora
et al., 2004). Their approach employs phenomeno-
logy to establish a set of essential features that dis-
tinguish the values that are measured, which leads to
categorising sensors into six groups: optical, mecha-
nical, thermal, electrical, magnetic, and chemical.
The integration of eHealth (Arning and Ziefle,
2009) within smart environments will create a safe
and intelligent environment for the disabled and the
elderly, the main challenge is to determine the level
of dependency of the beneficiaries, which will help
reducing the economical impact to governmental ins-
titutions on this matter.
In France, an autonomy assessment tool was lo-
cally devolved under the name: Autonomy Geronto-
logy Iso-Resources Groups (Autonomie G
´
erontologie
Groupes Iso-Ressources (AGGIR)), it is based on a
standard adopted by the French government in 2008
(dec, 2008). The AGGIR grid (Roudier and Al-
Aloucy, 2004) is a six-level scale (GIR1 to GIR6),
these dependence levels can be defined based on set
of seventeen three-state variables. Each variable can
have one of these values: A for complete depen-
dency, B for partial dependency, and C for complete
independency. The variables are classified into two
groups: discriminatory and illustrative variables. Ta-
ble 1 provides an overview for those variables previ-
ously mentioned.
3 DOMAIN SPECIFIC
LANGUAGE
In this section, we will make a brief presentation of
the proposed DSL. After that, we will show how can
DSL be used to describe the events that are sensed by
the sensors within a specific time range.
Table 1: AGGIR discriminatory variables.
Discriminatory Variable Evaluated Concept
Coherence Logical and sensible behavior
Location Place and time recognition
Toileting Body toileting
Dressing Body dressing
Self-feeding / Alimentation Self-Serving and eating
Elimination Hygiene management
Transfers Basic movements abilities
Indoor movement Need of technical assistance
Outdoor movement Need of technical assistance
Distant communication Use tele-communication technologies
We propose a Domain Specific Language (DSL)
in order to express to situations related to the AGGIR
constants that respond to the activities performed by
people with a physical or mental disability, support
for elderly, diseases connected to aging; which will
allow to express situations related to the maintenance
of people at home (Ram
´
ırez et al., 2016); due to the
fact that domain specific languages are recognized as
an effective manner to increase the productivity and
quality of software development
1
.
Depending on both the scope and the user com-
munity it targets, there exist several definitions for a
DSL (Mernik et al., 2005; Consel, 2004; Van Deursen
et al., 2000). The language must be able to describe
the data that one wishes to recover from the various
sensors present in a house and the operations related
to them.
We propose to represent the DSL by means of a
graphical user interface (GUI), in order to describe
complex events. In this context, a complex event is
considered as an activity performed by an inhabitant
that is detected by several sensors at the same time.
We consider that a graphical DSL would be easier to
handle than a textual language, since the the future
user might not be necessarily a person who is ackno-
wledged in the programming field.
We propose to represent activities performed by
the elderly or handicapped people within a home en-
vironment, for this reason it is imperative to be aware
when such activity takes place, as well as if there ex-
ists repetition or periodicity during the interval of its
performance. By implementing such a metholody, we
intend to detect anomalies on the behaviour of the in-
habitants, so we can assure coherence of the activities
on their daily living.
The textual specifications generated by DSL
Graphical User Interface (GUI) can be used to des-
cribe events from an operation perspective. Such as an
operation is measuring one of the following options: a
value, a maximum or minimum value, an average of a
1
http://www.dsmforum.org/
Proposal and Validation of a Domaine Specific Language for the Representation of the AGGIR Constants
439
set of values, or graphically displaying measured va-
lues within a time domain. The operations described
below were employed for developing the aforementi-
oned interface:
The Value operation: which returns the value (s)
of the device
The Maximum operation: which returns the maxi-
mum value of the value (s) of the device
The Minimum operation: Returns the minimum of
the value (s) of the device
The Average operation: which returns the
average of the value (s) of the device
The Graphic operation: returns a graphic with the
value (s) of the device
In addition, there are multiple possibilities to des-
cribe time using DSL. This includes determining a
specific date or description of a time range starting
from a particular date or between two-time points re-
presenting the beginning and end of the domain. The
specified time points can be either a date for a day or
hours within a day:
The operation Value can be calculated for the va-
lues:
On a specific date
Between two hours
Between two dates
From a specific date
The operations: Maximum, Minimum, Average,
Graphic, will be calculated for the values:
Between two dates
From a date
Total (all available values for the device)
After selecting the operation as well as the desired
calculation means, it only remains to specify the date
or the time according to what has been previously se-
lected.
Moreover, the feaures presented on the DSL are:
When a device is placed on the manager, the diffe-
rent operations which are available for it will ap-
pear.
Depending on the operation that has been chosen,
several options will be displayed in order to select
a suitable means for the calculation.
Once the previous step has been completed, it will
be possible to select the parameters for the calcu-
lation
When all the choices have been made, a summary
will be shown on the DSL manager interface; right
where the parameters were previosly displayed.
All that remains is to validate the choices that have
beeen made.
Figure 1: Display of results.
The result will be displayed in different manners,
depending on the operation and the selected para-
meters (Fig. 1).
For this previous matter, the general formula for
describing an event determined by a sensor <v1> that
measures an operation <v2> created by person <v3>
activates on date <v4> within a specified time range
specified using the hours <v5> and <v6> is:
Dispositi f <v1>operation<v2>Personne<v3>
Date<v4>Heure1<v5>Heure2<v6>
If the variable <v2> is selected to be
the Graphic operation (Graphique) or the
Average operation (Moyenne), then an additional op-
tion must be selected, it represents the time unit in
which the results need to be displayed, and the for-
mula takes the following form:
Dispositi f <v1>operation<v2>TypeOperation
<v3>Personne<v4>Date<v5>Heure1<v6>
Heure2<v7>
The textual information present in the result can
be saved in order to be reused, and thus facilitating
to find the analysed data without performing any ma-
nipulation once again, as shown below. It allows
its reusability by different context-aware applications,
thus, not being limited only to the AGGIR constants.
D i s p o s i t i f [ EMGSensor 11917 e f 4 c 0 ] O p e r a t i o n [ G r a ph i qu e ]
T y p e O p e r a t io n [ h o r a i r e ] P e r s o n n e [ au c u n e ]
Date [ 2 5 / 0 4 / 2 0 1 7 ] Heure 1 [ 1 1 ] Heu r e2 [ 1 3 ]
3.1 Sensors
With regard to identification of activities of daily li-
ving (ADL) by means of several sensors for providing
non intrusive monitoring, we propose a group of sen-
sors that can describe such activities. Those ones are
enlisted in Table 2, where some examples of their use
are proposed. Additionally data attributes and data
types for each sensor are indicated.
Additionaly, relevant data for each performed task
by the inhabitants is considered, in order to obtain in-
formation to achieve the identification of the AGGIR
constants after every activity has been carried out to
completion.
The above-mentioned data is represented on Table
3. Such data collection is necessary to keep history of
HEALTHINF 2018 - 11th International Conference on Health Informatics
440
Table 2: Activity recognition.
Sensor type Attributes / Data type
Electromagnetic sensor (Examples: On–Off / Boolean
Cooker/Stove, oven, light switch)
Proximity sensor (Example: Sink) On–Off / Double
Capacitive sensor (Examples: Kitchen On–Off / Boolean
counter, chair).
Magnetic sensor (Examples: Refrigerator Open–Close / Boolean
door, cupboard doors).
Presence sensor On–Off / Boolean
all the activities performed by the inhabitants, by me-
ans of a log file which will be able to precise whether
an activity begins or ends, helping to manage which
activity has begun, or which activity has already en-
ded; as well to specify if an activity has already be-
gun, while in the meantime, there is another one that
occurs at the same time and/or that has not been finis-
hed yet.
Table 3: Additional data for each activity.
Extra data type for each task Data type
startTime Date / String
endTime Date / String
Duration Integer / Double
Location String
Day String / Integer
Furthermore, the created history log file will con-
sider the logical aspect to describe situations, i.e, if
the inhabitant is eating and its noon, it might seem
logical, but the fact that the inhabitant eating in the
toilet is not logical.
The proposed criteria to determine the parameters
for the example of the precedent paragraph, are: time
and space, and within the time dimension, we can also
find (i) Concurrency: for recognizing activities which
take place simultaneously, but they do not necessarily
require the user’s interaction at the same time. That is,
activities that have been started but not yet ended by
the inhabitant (Helaoui et al., 2011). (ii) Precedence:
for establishing a logical order of the activities, i.e.
going to the bathroom; and then washing his hands.
(iii) Simultaneity: for identifying which activity takes
most of the time from the user, when multitasking ca-
pabilities might be present, i.e. preparing meal and
calling on the phone; or watching television while ea-
ting. (iv) Recurrence: for determining a logical se-
quences of situations.
In the case where there is a recurrence of an acti-
vity, it is essential to define at what this activity is car-
ried out regularly; i.e., the fact that someone eats ten
times in one day can not be considered very coherent.
Besides the explanation given in the previous pa-
ragraphs, it is possible to have situations that are not
logical; one activity after another one that is not con-
sidered normal, i. e.: do the dishes and then eat.
As a result, the history log file is necessary to de-
duct the possible activities which will be performed
in the future, and to find a relationship among them
to assure a coherent behaviour. Such a file will per-
mit to obtain information whether it is from long or
short periods of time (i.e. one hour); making possible
the identification of complex situations such as dis-
placement inside the home environment, where data
collected through the timeline of activities is useful
to determine if the behaviour of the inhabitant can be
considered as normal.
The main objective is to present a DSL which will
allow to express the constants and the activities com-
posing the AGGIR grid. For this matter, we intend to
use a representation in the form of a plot. Moreover,
this plot will help providing a history for detecting
abnormal behaviorhealth status of the inhabitants, as
shown on Fig. 2. The validation and representation
are described in the next section.
Figure 2: Saving of results.
4 REPRESENTATION AND
VALIDATION OF THE DSL
4.1 Methodology and Criteria
This section is dedicated to discuss the methodology
and criteria used to gather and analyze information.
Firstly, we explain the structure of information col-
lected from the wireless sensor network. Secondly,
we explain the mechanism used to analyze the infor-
mation using DSL to describe events. Finally, we
show how to apply the previous criteria to calculate
the values of variables in the AGGIR grid.
4.1.1 AGGIR in-depth and the Complex Activity
Detection
AGGIR is an assessment system used to determine
the Autonomy of individuals by measuring a number
Proposal and Validation of a Domaine Specific Language for the Representation of the AGGIR Constants
441
of capacities and possibilities by means of describing
their existence in terms of fully or partially present or
nonexistent.
The system measures seventeen variables divided
into two groups, the first is called the discriminatory,
it includes ten variables: Coherence, Orientation, Toi-
leting, Dressing, Hygiene, Alimentation, Transfers,
movements (indoor, outdoor) and distant communica-
tion. As for second Group, it is called the illustrative,
it contains seven variables as follows: Management,
cooking, Housekeeping, transportation, Medical Pur-
chases, Medical treatment and leisure activities.
In the following set of experiments, three varia-
bles are concerned, they are Dressing, Hygiene and
Transfers. Dressing variable assesses the ability to
wear clothing, upper and lower parts of the human
body. Hygiene variable monitors an elderlys ability
to maintain his personal hygiene. Transfers variable
measures the possibility of getting up, lying down and
sitting, as part of daily activities.
The difficulty in determining the values of these
variables in a simulated environment lays in the va-
riables’ nature itself. While some can be measured
directly, such as sitting or lying down, some of them,
such as hygiene, have a complex context to determine,
based on the values of a number of sensors within a
limited time range.
The importance of DSL is shown in determining
complex events. It has the potential to describe events
that can be indirectly observed in the time domain.
The ”indirect” term in this context means that there is
no sensor to measure value immediately, but it rather
refers to collecting and analyzing the readings of a
number of sensors to calculate a value associated with
a complex event.
For example, personal hygiene is a complex event.
It is associated with a number of simple activities that
are performed within a limited time range, such as ba-
thing, toilet use, and hand hygiene. There is no stan-
dard approach to measuring such things, but it can be
estimated on average according to the existing routi-
nes of elders.
4.1.2 Proposal
The proposed methodology is described in the next
paragraphs:
Step 1. The first step is to prepare the scenario
for an elderly indoor daily routine over the course of
one week. The primary source of information used to
generate the scenario is the schedule proposed by the
work of (Yuan and Herbert, 2014) (Fig. 3), but many
modifications take place in order to make the scenario
more suitable for the simulation. However, the XML
format is used to describe the scenario programmat-
ically. By means of XML, it is possible to describe
events chronologically so the simulator can process
these files. Even though writing scenarios using XML
might seem impractical, we suggest this format in or-
der to develop the DSL appropriately.
Step 2. After the simulation is done, the simula-
tor organizes the resulting data into a set of records,
each of which represents an action captured by a sen-
sor (Fig. 4). Each record consists of data fields, such
as the time it occurred (according to the simulator
clock), the sensor ID and the sensed value. These are
raw data and need to be analyzed in order to generate
events and then calculate the values of the variables.
Step 3. The next step is to generate events. An
event is a composite act that is observed using more
than one sensor, which means that an event has more
than one record in raw data. The DSL is used to pro-
vide an accurate and unified description of the events.
To illustrate this, we offer a typical example of an
event related to hygiene: when the toilet is used, the
inhabitant should wash his hands after such an action
is finished. This is an event related to personal hy-
giene. In order to analize this event, the records cre-
ated by the presence of the sensor in the bathroom,
along with those ones issued by the use of the toilet
flush and the washbasin, must be examined.
Because of the nature of the AGGIR variables,
there is an urgent need to set up a criteria to be ap-
plied to generate the analysis of such events. If such
criteria is met, then the so-called variable will take a
positive value that means the elderly has the ability
to perform the activity/event that is being evaluated;
otherwise, it means that the individual does not have
the ability to carry out suach a task.
Although every variable in the AGGIR grid are ba-
sed on three major states, which state that the elderly
can either possess the ability to perform the activi-
ties concerning one variable, whether it is completely,
partially or does not possess it at all; this study covers
a proposition where only two cases out of three AG-
GIR variables are accomplished by the inhbitant, me-
aning that whether they are in complete possession of
the skills for perfoming the activities composing the
evaluated variable or simply not. In the conclusion,
we suggest a solution to this problem.
As a matter of fact, from the seven variables in
the AGGIR grid, we are able to automatically mea-
sure three by tracking and analyzing events resulted
of the inhabitant performed tasks from the simulation
within the icasa environment. The selected variables
are: toileting, transfer, and dressing. The mechanism
of the calculation of these variables is as follows:
To calculate the hygiene variable the following
HEALTHINF 2018 - 11th International Conference on Health Informatics
442
Figure 3: Schedule employed in the simulation.
Figure 4: Graphical description of the proposed methodo-
logy.
conditions must be met: the person must have a
bath four times a week at least, wash his hands
after eating or using the toilet, for at least three
times a day.
To calculate the transfer variable, namely the abi-
lity of a person to perform the basic movements of
his dayly routine, such as rising from bed, sitting
down and standing up from a chair; We consider
that there must be at least three sitting events a
day, either taking place in the living room or in
the kitchen, and at least rising from the bed one
time per day. The mechanism to measure the abi-
lity of the personto wake up after falling on the
ground is not covered in this approach.
To verify if the dressing variable is achieved, dres-
sing events like approching the wardrobe must be
encountered at least twice a day.
Moreover, the source code that analyzes the re-
cords and generates the events is written in Python
and run on the simulation host. It is written using
a function-oriented approach, this makes the Original
code scalable and future additions can be made to cal-
culate the rest variables in a facile way.
4.2 Experimental Results
All simulating and processing operations were perfor-
med by means of two sets of inputs for the simula-
Table 4: Results of the first scenario.
Transfer Hygiene Dressing
No. of events
MON
X
7
X
8
X
3
TUE
X
6
X
8
X
3
WED
X
7
X
11
X
2
THU
X
7
X
10
X
2
FRI
X
8
X
8
X
3
SAT
X
8
X
6
X
4
SUN
X
6
X
9
X
3
Total
X
49
X
59
X
19
Table 5: Results of the second scenario.
Transfer Hygiene Dressing
No. of events
MON
X
7
X
7
X
3
TUE
X
7
X
7 × 0
WED
X
7
X
11
X
2
THU
X
6
X
11
X
3
FRI
X
8
X
8
X
3
SAT × 3
X
6
X
4
SUN
X
6 × 6
X
2
Total
X
44 × 56
X
16
tor, in order to generate different scenarios. The em-
ployed inputs are text files written using the XML for-
mat. The files present the analyzed activities and ind-
oor movement of an elderly during a period of time of
one week. It is possible to simulate the whole week
in one file, but in order to facilitate the managing of
results, we separate the week into seven days, each of
which is represented using one file.
The first scenario is a simulation of an ideal week
where all the activities were performed by the inha-
bitant with no impediment into seven files, one file
for each day. The activities of the elderly were mo-
nitored using a simulated sensor network in the house
environment. The daily activities are: waking up, pre-
paring food, hygiene, going to the toilet, watching te-
levision or reading, accessing and leaving the house
for short periods of time. See Table 4.
In the second scenario, we deliberately dropped
some daily activities in a way that we can cause a
malfunctioning on the criteria we developed, the days
were randomly chosen. The simulation result of this
scenario are issued on seven files, one for each day of
the week. See Table 5
Due to the fact that the methodology employed
in the calculation is event-oriented and not record-
Proposal and Validation of a Domaine Specific Language for the Representation of the AGGIR Constants
443
oriented, that makes it more intelligent and context-
aware oriented. It is capable of understanding and
analyzing the complex activities of the proposed envi-
ronment, and then calculating the value of the variable
on this basis.
Table values show that our method was able to de-
termine the values of the three variables in both sce-
narios although the change in the number of transfer
and hygiene events was not significant. However, the
days on which the variable’s value was negative were
determined.
The success of detection is accomplished because
the method does not relie on the number of simple
events when calculating the variables, but it depends
on the generation of complex events.
The experiment was designed to examine three
concepts: the first is calculating the constants of the
AGGIR grid: dressing, transfer and hygiene. using
the suggested method. The second is the scalability,
where we expand the time frame to verify the abi-
lity of the algorith to deal with larger time domains
and thousands of records and events. Finally, we exa-
mined algorithm performance for different simulation
times.
Firstly, the method succeeded in identifying three
simulated problems within a week. The days were
chosen randomly. Fig. 5 and Fig. 6 show that des-
pite the number of records in the second scenario re-
lated to personal transfer and personal hygiene did not
change significantly compared to the first analyzed
scenario, however a problem with the dressing vari-
Figure 5: Transfer events.
Figure 6: Hygiene events.
able was detected. This, in turn, reflects the how the
methodology can perform a smart analysis of events.
Next, we tested the scalability of the algorithm in
a time domain greater than one week. For this matter,
we simulated three months and generated the corre-
sponding records. After that, we applied the criteria
used to create the events, and finally, we measured
the values of the previous three constants; as shown
in Table 6.
Table 6: Number of generated events in three months.
Month 1 Month 2 Month 3 Total
Transfer 210 207 206 623
Hygiene 253 249 245 747
Dressing 90 88 80 258
We assumed that each month consisted of thirty
days, precisely four weeks and two days, which allo-
wed flexibility when processing the records and ge-
nerating events. By doing so, there is a possibility to
use the actual number of days within the months, i.e.
(28, 29, 30 and 31) days (Fig. 7), requiring further
processing.
Figure 7: Algorithm scalability.
Finally, to make sure that the algorithm is scalable,
we monitored the time elapsed to calculate the con-
stants in order to simulate a day, a week, two weeks,
three weeks, a month, two months, and three months.
Table 7 shows the elapsed time for each case. The va-
lues displayed include the time spent for each simu-
lation, as well as results analysis, events generation,
and finally the calculation of the constants variable.
Table 7: Real time elapsed to calculate the constants in se-
ven different simulation time ranges (Day, Week, Month).
Time period 1D 1W 2W 3W 1M 2M 3M
No. of days 1 7 14 21 30 60 90
Time (s) 62 434 867 1301 1863 3713 5590
Fig. 8 shows the performance of the algorithm
with simulating scenarios with different time ranges.
The resulting diagram is linear, which corresponds to
the complexity of the algorithm, represented by O(n),
where n represents the number of events, meaning
that the algorithm is scalable.
HEALTHINF 2018 - 11th International Conference on Health Informatics
444
Figure 8: Analysis of Algorithm performance.
5 CONCLUSION
In this Article, we introduced the AGGIR model, a
special system for determining the autonomy of an
inhabitant adopted by the French government in the
past decade. After that, we show a special language,
the DSL, which is intended to describe activities in the
time domain. Next, we explained our own mechanism
for calculating three of AGGIR variables. Finally, we
presented the results of two simulated scenarios were
analyzed using the previous methodology in order to
examine the criteria we developed. In addition to that,
we tested the scalability of the algorithm.
The automation process of AGGIR is a long-term
process. The system must be tested in many sce-
narios, especially the abnormal ones, which contain
readings representing the occurrence of accidents or
unexpected behavior of the elderly, in order to see the
ability of the system to understand the records cor-
rectly and thus generate appropriate events.
We also look forward to developing the value of
the variables being calculated. As noted above, the
variables in AIGGR are three-fold, whereas in our
study they are binary. Moving to triple-value varia-
bles requires a deeper understanding of the ability that
is being checked, especially as many of variables re-
present principles that cannot be measured using sen-
sors such as the coherence. In this context, we suggest
developing a point system in which an individual gets
a number of points based on activities, and the out-
come is assessed at the end according to the earned
points.
The current system is neither proactive nor inte-
ractive. It depends on analysis of pre-existing sensors
results. In the next step, we are looking forward to
including the concept of real time. In this case, ap-
propriate mechanisms for generating events should be
developed. Finally, the speed of response when a pro-
blem is identified must be taken into account.
REFERENCES
(2008). D
´
ecret n
o
2008-821 du 21 ao
ˆ
ut 2008 relatif au guide
de remplissage de la grille nationale AGGIR.
Arning, K. and Ziefle, M. (2009). Different perspectives on
technology acceptance: The role of technology type
and age. In Symposium of the Austrian HCI and Usa-
bility Engineering Group, pages 20–41. Springer.
Arora, A., Dutta, P., Bapat, S., Kulathumani, V., Zhang, H.,
Naik, V., Mittal, V., Cao, H., Demirbas, M., Gouda,
M., and others (2004). A line in the sand: a wireless
sensor network for target detection, classification, and
tracking. Computer Networks, 46(5):605–634.
Boulos, M. N. K., Lou, R. C., Anastasiou, A., Nugent,
C. D., Alexandersson, J., Zimmermann, G., Cortes,
U., and Casas, R. (2009). Connectivity for Healthcare
and Well-Being Management: Examples from Six Eu-
ropean Projects. Int. J. Environ. Res. Public Health,
6:1947–1971.
Consel, C. (2004). From a program family to a domain-
specific language. In Domain-Specific Program Ge-
neration, pages 19–29. Springer.
Helaoui, R., Niepert, M., and Stuckenschmidt, H. (2011).
Recognizing interleaved and concurrent activities: A
statistical-relational approach. In Pervasive Compu-
ting and Communications (PerCom), 2011 IEEE In-
ternational Conference on, pages 1–9. IEEE.
Lalanda, P., Hamon, C., Leveque, T., and others (2014).
iCasa, a development and simulation environment for
pervasive home applications. In 2014 IEEE 11th Con-
sumer Communications and Networking Conference
(CCNC).
Li, R. Y. M., Li, H. C. Y., Mak, C. K., and Tang, T. B.
(2016). Sustainable Smart Home and Home Automa-
tion: Big Data Analytics Approach.
Liau, W.-H., Wu, C.-L., and Fu, L.-C. (2008). Inhabitants
tracking system in a cluttered home environment via
floor load sensors. IEEE Transactions on Automation
Science and Engineering, 5(1):10–20.
Mernik, M., Heering, J., and Sloane, A. M. (2005). When
and how to develop domain-specific languages. ACM
computing surveys (CSUR), 37(4):316–344.
Ram
´
ırez, J. M. N., Roose, P., and Dalmau, M. (2016). Dis-
tributed interfaces and context-oriented broadcast ser-
vices in a smart-home environment. In Wireless and
Mobile Computing, Networking and Communications
(WiMob), 2016 IEEE 12th International Conference
on, pages 1–8. IEEE.
Roudier, M. and Al-Aloucy, M. J. (2004). A principal com-
ponent analysis of the AGGIR scale in demented el-
derly patients. Revue neurologique, 160(5 Pt 1):555–
558.
Van Deursen, A., Klint, P., Visser, J., and others (2000).
Domain-specific languages: An annotated biblio-
graphy. Sigplan Notices, 35(6):26–36.
Varshney, U. (2003). Pervasive healthcare. Computer,
36(12):138–140.
Vetel, J. (1994). AGGIR: guide pratique pour la codification
des variables. Rev. Geriatrie, 3:249–259.
Yuan, B. and Herbert, J. (2014). Context-aware hybrid rea-
soning framework for pervasive healthcare. Personal
and ubiquitous computing, 18(4):865–881.
Zhang, D., Yu, Z., and Chin, C.-Y. (2005). Context-aware
infrastructure for personalized healthcare.
Proposal and Validation of a Domaine Specific Language for the Representation of the AGGIR Constants
445