7 th Framework Programme Miraculous-Life Grant Agreement No. 611421 Confidential Miraculous-Life i Project Identification Project number No. 611421 Duration 1 st Dec 2013 – 30 th Nov 2016 Coordinator Andreas Hochgatterer Coordinator Organisation AIT Austrian Institute of Technology GmbH, Austria Website www.miraculous-life.eu Miraculous-Life Miraculous-Life for Elderly Independent Living Document Identification Deliverable ID: D4.1.a Design and specification of ICT-based services and safety services Release number/date V1.2 (a) 19 August 2014 Checked and released by Panayiotis Andreou Work Status Finished Review Status Accepted Key Information from "Description of Work" Deliverable Description Design and specification of ICT-based services and safety services Dissemination Level PU=Public Deliverable Type R = Report Original due date (a) 31 July 2014 Authorship& Reviewer Information Editor Panayiotis Andreou Partners contributing UCY: Panayiotis Andreou (PA), Andreas Konstantinidis (AK), Nikos Cosma (NC) Citard: Christophoros Christophorou (CC) AIT: Emanuel Sandner (ES), Sten Hanke (SH) UniGe: Cristiana Tsiourti (CT), Marios Aristogenis Fanourakis (MA),
Transcript
7
th Framework Programme
Miraculous-Life
Grant Agreement No. 611421
Confidential Miraculous-Life i
Project Identification
Project number No. 611421
Duration 1st Dec 2013 – 30
th Nov 2016
Coordinator Andreas Hochgatterer
Coordinator Organisation AIT Austrian Institute of Technology GmbH, Austria
Website www.miraculous-life.eu
Miraculous-Life Miraculous-Life for Elderly Independent Living
Document Identification
Deliverable ID: D4.1.a Design and specification of ICT-based services and safety services
Release number/date V1.2 (a) 19 August 2014
Checked and released by Panayiotis Andreou
Work Status Finished
Review Status Accepted
Key Information from "Description of Work"
Deliverable Description Design and specification of ICT-based services and safety services
Table 9 - Monitoring/Tracking- Fall Detection Service Methods Description 30
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life ix
Abbreviations
Abbrev. Description
AAL Ambient Assisted Living
API Application Programming Interface
ICT Information and Communications Technology
CoNet Collaborative Care Network
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 1
Executive Summary
A major aim of the Miraculous-Life project is to design and develop a number of advanced technologies and technology enabled services to support elderly in their everyday activities.
The main objective of this deliverable is to realize the ICT services that support the daily home activities of end users based on the requirements and use case scenarios gathered during WP1. A number of services are designed and developed that can be categorized as follows:
i) Care & Wellness services that provide hygienic and basic household advising and personal support (like open the window when you wake up, wash your teeth) and enable the elderly to continue managing their daily activities in their home;
ii) Guidance services that provide assistance in locating personal items as well as encourage the end users to build enduring habits for a healthy life; and
iii) Education/Leisure services that advice the elder by aiding its daily activities through education facilities such as communicating new meal preparation recipes and also by enhancing its social activities.
iv) Safety services are provided bestowing the elder with the feeling of safety in carrying out its daily life.
This is the first version of the deliverable D4.1 (D4.1a) and here we provide the architectural design and functional specification of ICT services. Note that the presented functionality is expected to evolve, throughout the lifetime of the project, according to the changing needs and requirements of the end users and the other related stakeholders (i.e., the elder, the caregivers, etc.) and also the supporting functionality (if any) that the other components of the Miraculous-Life system will demand from the ICT-services. Thus, the overall architecture design and the functional specification of the ICT-services will need to change or be adapted/ enhanced in order to accommodate these new needs and requirements. These changes/enhancements will be described in the second version of this deliverable (D4.1b) which is due to month 24 of the project.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 2
1 About this Document
1.1 Role of the deliverable
The role of this deliverable is to develop a set of Home Daily ICT services considering the categories of: Care & Wellness, Guidance, and Education/Leisure aiding the elder in the execution of determined daily life activities at home making use of the collaborative care network as well as a set of safety services to maintain the elderly healthy lifestyle.
This is the first version of the deliverable D4.1 (D4.1a) that provide design, implementation and testing of most Home Daily ICT services, databases, methods and the interrelation\connection between them. In particular in this first version, we provide technical details regarding the Agenda and Medication services that are under the care and wellness schema, the Object Location Assistance and Motivation for physical activity services that are under the guidance schema as well as the event and meal assistance services, which are under the Education and Leisure schema. Similarly, it also provides technical details regarding safety services such as Fall detection and Notification.
The technical details have been identified by taking into consideration the initial requirements and needs of the end users inferred from the first versions of D1.1a and D1.2a developed in WP1. Note that the methodology provided by Home Daily ICT services and safety services is expected to continuously evolve, thought out the lifetime of the project, according to the changing needs and requirements of the end users and the other related stakeholders and also the supporting functionality (if any) that the other components of the Miraculous-Life system will demand from this component. These changes/enhancements will be described in the second version of this deliverable (D1.2b) which is due to month 24 of the project.
This deliverable will be mainly considered by the technical partners of WP4 for the development of Home Daily ICT-based activity services. Moreover, this deliverable will also provide input to WP1, WP3 and WP5 for further implementation, integration and overall system validation work.
1.2 Relationship to other Miraculous-Life deliverables
The deliverable is related to the following Miraculous-Life deliverables:
Deliverable: Relation
D1.1
Specification of user needs analysis and design of VSP model: This document presents the needs and requirement of the end users from the Miraculous system.
In the current deliverable we translate the end user needs and requirements into the technical specification of the system.
D1.2 Specification of use case scenarios and User Interface: This document presents the use case scenarios that the Miraculous system will support.
In the current deliverable we translate the use case scenarios into the technical specification of the system.
D4.2 Specification of Co-Net: This document presents the design of the Collaborative care Network (Co-Net). D4.1 will provide input to D4.2 for considering the needs of the Home Daily ICT (in terms of socialization and profile aspects) from Co-Net for the enhancement or creation of new tables as well as the development of new Application Program Interfaces (APIs) that Co-Net should support.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 3
D5.2 Specification and development of the Knowledge Base: The goal of this deliverable is the development of the Knowledge Base that will facilitate the main data hub of the MiraculousLife system
The data structures of the D4.1 services are included in the Knowledge Base and the services implementation is built on top of the D5.2 database API.
D5.3 Specification of Miraculous-Life system integration: The key goal of this deliverable is to design and specify the overall system architecture and to present how the different system prototype components developed in WP2-WP4 will be integrated into a coherent system architecture.
In the current document we consider the technical infrastructure, standards, specifications and strategies to be followed throughout the building, testing, and implementation of the system and we adapt its design accordingly.
D5.4 System integration validation: The main task of this deliverable is the assembly and integration of the different components developed in WP2 and WP3 and WP4 into the complete prototype system.
The current document will provide input to D5.4, for the integration and validation of Home Daily ICT-based Services into the coherent Miraculous system.
1.3 Structure of this document
This document is structured as follows. Chapter 2 presents the general idea of how Home Daily ICY-based services are designed, implemented and what they will support via use cases, database design and service design specifications. Similarly Chapter 3 provides in detail the design and implementation of the Safety services via use cases, database design and service design specifications. Finally, Chapter 4 concludes this report.
Chapter 2 provides the data dictionary for the database tables currently managed by the Co-Net’s components. Chapter 3 presents in more details the design of the methods (methods dictionary) currently supported by Home Daily ICY-based services and safety services components, describing in detail the input parameters, the main functionality and the output that each method will return.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 4
2 Home Daily ICT-based Services Design
Home Daily ICT-based Services Design is one of the most important components of the Miraculous-Life approach. It mainly focuses to support the daily home activities of an elderly user via the following:
1. Care and Wellness Services: This type of services contributes to the care and wellness of the elderly. More specifically, it will provide the following:
Agenda Service: is responsible to keep track certain activities related to an
elder.
Medication Service: provides medical information related to a specific elderly.
2. Guidance Services: this category will comprise services dedicated to helping the elderly cope with daily life problems and household activities and guide their safe execution through the day. It will provide for stimulation and support to maintain a healthy lifestyle via the following:
Object Location Assistance: serves as a “memory support” that helps the elderly to remember where certain objects are usually stored around the house.
Motivation for physical activity: stimulates and motivates the user to take physical activity.
3. Education & Leisure Services: This type of services advises the elder by aiding its daily activities through education facilities such as communicating new meal preparation recipes and also by enhancing its social activities providing the following:
Event Service: allows a user to invite other members to participate in group
leisure activities.
Meal Assistance Service: is responsible to provide information regarding meals,
their recipe, the ingredients of a meal, etc., associated to a person.
In the following sections, find detailed descriptions of the services along with technicalities regarding the database, methods designed and implemented through use cases, ER diagrams and dictionaries.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 5
2.1 Care and Wellness – Agenda Service
The agenda service is responsible to keep track certain activities related to an elder. In particular, it provides details regarding agenda items that an elder should consider and/or attend. Those details may include a start-date, end-date and description, location, precaution of an agenda item, if it should be taken\attended during the day or night etc. This information is used to automatically create a personal calendar entry (named Calendar Item) for each elder. Since a Calendar Item may be repeated at periodic time intervals (e.g., play chess each week), it is supplemented by a number of recurrence rules. As a result, each calendar item generated a number of agenda items that define the individual occurrences of the calendar entry. The latter may then be queried by the notification service as well as be provided to the user via a graphical user interface.
Agenda Service
Users
Avatar
Caregiver
D3. Provides Agenda Information
Agenda Items
Calendar Items
Notification Service
B1. Queries for active Agenda Items
B2. Gets active Agenda Items
Agenda Daemon
D1. Queries for active Agenda Items
D2. Gets active Agenda Items
A1. Create Calendar Items
Figure 1 – High-level interaction diagram
Figure 1 details the agenda service main features. A caregiver is able to create calendar items and store them to the Calendar data structures. The agenda service utilizes a daemon process (named the agenda daemon), that periodically checks the calendar for active calendar items and generated new agenda items for each person. It also checks for any updates, insertions and/or deletions for updating the Agenda table accordingly. The new agenda items generated by the agenda daemon are inserted in the Agenda data structures. The agenda items are then used by the CoNet Notification Service described in deliverable D4.2 to generate notifications (i.e., reminders). Finally, the avatar periodically and consecutively checks the agenda data structures and provides agenda information to the elderly with respect to agenda items that should be performed and/ be attended via a graphical user interface.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 6
2.1.1 Use cases
In this section, the individual use cases of the agenda service are presented and described.
Agenda Service
Create Calendar Items for Elderly
Caregiver
Manage Calendar Entries
Elderly
Update Calendar Items for Elderly
Delete Calendar Items for Elderly
<<include>>
<<include>>
<<include>>
<<include>>
Agenda Daemon
Figure 2 - Caregiver and Elderly Manage Calendar Use Case
Figure 2 illustrates a use case scenario that demonstrates the management of calendar items by the care givers and elderly persons. A caregiver may create a calendar item for a particular elder or group of elders as part of his activities. An elder may decide to accept this calendar item and additionally create his own ones and update or delete existing ones. Each time a create or delete calendar item occurs, the agenda daemon is invoked in order to generate the corresponding agenda items and maintain consistency between calendar and agenda entries. Finally, when an update calendar entry event occurs, the Agenda service does not actually update the calendar entry but instead deletes the existing one (thus removing all related agenda entries) and then creates a new one (thus generating new agenda items).
AgendaDaemon
Agenda Service
Requests Active and unprocessed Calendar Items
Generated new Agenda Items
Figure 3 - Agenda Daemon Use Case
Figure 3 shows a use case regarding the responsibilities of the agenda daemon. The agenda daemon mainly generates agenda items and periodically requests for active and unprocessed calendar items.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 7
Agenda Service
Avatar
Query for Daily Agenda Items
of a Person
Query for Weekly Agenda Items
of a Person
Query for Monthly Agenda Items
of a Person
Query for Custom Date Range
Agenda Items of a Person
Figure 4 - Avatar Use Case
Figure 4 shows a use case regarding the activities of the avatar. In particular, the avatar is responsible to query the agenda data structures according to different time intervals (e.g., daily agenda items, weekly agenda items, monthly agenda items, etc.) for a particular person as well as agenda items for a specific date range.
Notification Service
Agenda Service
Gets Active Agenda Items
Figure 5 - Notification Service Use Case
Figure 5 shows a notification service use case where this particular service retrieves active agenda items from the agenda items database. Please refer to deliverable D4.2 for more details on the Notification Service.
2.1.2 Database Design
In this section, we provide the current database design of the Agenda Database Design. The database schema shown in Figure 6, presents the Entity Relationship (ER) schema of the Agenda service included in the care and wellness schema and its interaction with KnowledgeBase and Monitoring. All the tables currently included in this database are described in Table 1.
However, for more details about the attributes included in each table as well as the type and the description of these attributes please refer to Appendix A.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 8
Table Name Description
Agenda.PERSON_CALENDAR This table stores information about a Calendar Item of an elder. It contains the recurrence rules of this calendar item.
Agenda.PERSON_AGENDA This table stores the actual agenda items of an elder.
Agenda.PERSON_FEEDBACK This table stores the user feedback regarding a specific agenda item.
Note: The available values are: 1. Requires Feedback (The agenda item requires to be accepted/rejected or put tentative), 2. Accepted (The agenda item has been accepted) 3. Rejected (The agenda item has been rejected. It will be maintained for archive purposes) 4. Tentative (The agenda item has been put as tentative and will be brought up again for acceptance or rejection.)
Agenda.PERSON_CALENDAR_TYPE
This table stores the type of each particular calendar item related to an elder.
Note: The available values are: 1. Calendar Item, 2. Task, 3. Medication Calendar Item, 4. Birthday/Anniversary Item.
Table 1 – Care and Wellness Agenda Database Tables
In order to protect the structure and data of the base tables, we have implemented the VIEW_AGENDA_ITEMS and VIEW_CALENDAR_ITEMS view structures that provide all data required by the AgendaService methods.
D4.1.a - Design and specification of ICT-based services and safety services
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 10
2.1.3 Methods Description
The Agenda service in order to achieve the functionality referred above will provide the following web services:
In this section, we provide the description of the methods currently supported by the Agenda service. These methods allow the organization and management of the Calendar and Agenda Items of a specific elder.
All the methods currently supported by the Agenda service are described in Table 2. However, for more details about these methods (i.e., input parameters, functionality and output parameters) please refer to Appendix A.
Method Name Description
LIST_PERSON_AGENDA_FEEDBACK Retrieves a list of all AgendaItemFeedback objects from table PERSON_CALENDAR_FEEDBACK.
LIST_PERSON_CALENDAR_TYPE Retrieves a list of all PersonCalendarType objects from table PERSON_CALENDAR_TYPE.
DELETE_PERSON_AGENDA Deletes an existing record from table PERSON_AGENDA
DELETE_PERSON_CALENDAR Deletes an existing record from table PERSON_CALENDAR
DELETE_PERSON_AGENDA_FEEDBACK Deletes an existing record from table PERSON_AGENDA_FEEDBACK
DELETE_PERSON_CALENDAR_TYPE Deletes an existing record from table PERSON_CALENDAR_TYPE
GET_PERSON_AGENDA Retrieves a PersonAgenda object.
GET_PERSON_CALENDAR_ITEM Retrieves a PersonCalendarItem objects.
GET_PERSON_CALENDAR_ITEMS Retrieves a list with all PersonCalendarItem object.
GET_PERSON_AGENDA_FEEDBACK Retrieves an AgendaItemFeedback object.
GET_PERSON_CALENDAR_TYPE Retrieves a PersonCalendarType object.
GET_PERSON_AGENDA_START_END_DATE Retrieves an AgendaItem object.
GET_PERSON_DAILY_AGENDA Retrieves a list with AgendaItem objects for a specific day.
GET_PERSON_WEEKLY_AGENDA Retrieves a list with AgendaItem objects for a specific week.
GET_PERSON_MONTHLY_AGENDA Retrieves a list with AgendaItem objects for a specific month.
INSERT_PERSON_AGENDA Inserts a new record into table PERSON_AGENDA
INSERT_PERSON_AGENDA_FEEDBACK Inserts a new record into table PERSON_AGENDA_FEEDBACK
INSERT_PERSON_CALENDAR Inserts a new record into table PERSON_CALENDAR. Additionally, it invokes the Agenda Daemon process to generate new agenda items based on the new calendar item.
INSERT_PERSON_CALENDAR_TYPE Inserts a new record into table PERSON_CALENDAR_TYPE
INSERT_PERSON_WEEKLY_CALENDAR Inserts a new record into table PERSON_WEEKLY_CALENDAR
INSERT_PERSON_MONTHLY_CALENDAR Inserts a new record into table PERSON_CALENDAR
INSERT_EVENT_AS_PERSON_CALENDAR Creates a single Calendar Item once into table
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 11
PERSON_MONTHLY_CALENDAR
UPDATE_PERSON_AGENDA Updates an existing record from table PERSON_AGENDA by deleting the existing record and creating a new one this invoking the Agenda Daemon.
UPDATE_PERSON_AGENDA_FEEDBACK Updates an existing record from table PERSON_AGENDA_FEEDBACK
UPDATE_PERSON_AGENDA_SET_FEEDBACK Updates an existing record from table PERSON_AGENDA_SET_FEEDBACK
UPDATE_PERSON_CALENDAR_TYPE Updates an existing record from table PERSON_CALENDAR_TYPE
UPDATE_PERSON_CALENDAR
Updates an existing record from table PERSON_CALENDAR. Since there are agenda items correlated with each calendar item, the process removes the previous agenda entries, then creates the new calendar item and then calls the daemon in order to generate the new agenda items.
DAEMON_AGENDA Periodically invoked by the agenda daemon thread to create agenda items from calendar items.
Table 2 – Care and Wellness Agenda Service Methods Description
2.1.4 Recurrence Format
In this section we provide specifics regarding how to interact with the method INSERT_PERSON_CALENDAR/UPDATE_PERSON_CALENDAR for the benefit of the developers.
In order for the Agenda Service to handle recurrence events, we utilized the calendar component that stores the rules of recurrences. A periodically executed component, called the Agenda Daemon, translate those recurrences to agenda items. In other words, the insertion of new events are stored to the calendar table (PERSON_CALENDAR) and the retrieval from the agenda table (PERSON_AGENDA). Therefore, one calendar item can produce multiple agenda items depending on its recurrence. In more detail, for each calendar item, the daemon generates all occurrences for one year at the time until the number of occurrences or the recurrence date is reached. In the following table, is presented a more detailed description of the PERSON_CALENDAR table.
Field Name Type Nullable Default Value
Constraints
REMINDER_TIME int No 0 N/A
This represents the notification reminder time in minutes. Note that negative values represent that the notification will be triggered before the event while positive values (highly improbable) represent that the notification will be triggered after the event.
WEEK_DAY_PATTERN int No 127 Between 1 and 127
This represents a coding scheme that has been devised for easily entering a week days pattern. More specifically, we have coded each day with a number (following a binary approach) as
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 12
follows:
1=Monday
2=Tuesday
4=Wednesday
8=Thursday
16=Friday
32=Saturday
64=Sunday
For example, if the calendar item should be repeated every Wednesday, Thursdays and Sunday then the field should be set to 76 (i.e., 4=Wednesday + 8=Thursday + 64=Sunday). All days are represented by the total sum of all days which is 127.
DAY_FREQUENCY int Yes Larger or equal to 1
This represents the daily frequency of the calendar item, i.e. 1 represents every day, 2 represents every second day, 3 represents every third day, etc.
EXACT_DAY int Yes NULL or between 1 and 31
This represents a calendar item that occurs a specific day of the month, e.g., 4th day of the month.
OCCURRENCE_NO int Yes NULL or >=0
This represents a specific occurrence. We have coded this as follows: 1 represents the first occurrence, 2 represents the second occurrence, 3 represents the third occurrence, etc. Additionally, we have coded the last occurrence as 0.
OCCURRENCE_TYPE int Yes NULL or between 1 and 3
This represents how occurrences are grouped (e.g., by week, by month). We have coded this as follows: 1 represents weekly grouping, 2 represents monthly grouping, 3 represents yearly grouping. A NULL value represents no grouping.
WEEK_FREQUENCY int No 1 >=1
This represents the weekly frequency of the calendar item, i.e. 1 represents every week, 2 represents every second week, 3 represents every third week, etc.
EXACT_WEEK int Yes NULL or between 1 and 53
This represents a calendar item that occurs a specific ISO week of the year.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 13
MONTH_PATTERN int No 4095
This represents a coding scheme that has been devised for easily entering a monthly recurrence pattern. More specifically, we have coded each month with a number (following a binary approach) as follows:
1=January
2=February
4=March
8=April
16=May
32=June
64=July
128=August
256=September
512=October
1024=November
2048=December
For example, if the calendar item should be repeated every January, April and August then the field should be set to 137 (i.e., 1= January + 8= April + 128=August). All months are represented by the total sum of all months which is 4095.
MONTH_FREQUENCY int No 1 >=1
This represents the monthly frequency of the calendar item, i.e. 1 represents every month, 2 represents every second month, 3 represents every third month, etc.
YEAR_FREQUENCY int No 1 >=1
This represents the yearly frequency of the calendar item, i.e. 1 represents every year, 2 represents every second year, 3 represents every third year, etc.
OCCURRENCES int Yes NULL or >=1
This represents the maximum number of occurrences of the calendar item. For example, setting a value of 6 will limit the number of occurrences to 6 irrespectively if the recurrence rules generate a larger number of occurrences.
RECURRENCE_END_DATE
date Yes
This represents the maximum recurrence end date of the calendar item.
As mentioned above, the Agenda Daemon runs through the PERSON_CALENDAR and finds the active calendar items and stores them in the PERSON_AGENDA table. By active calendar items, we mean the items that (i) their dates are between the calendar start date (START_DATE_TIME) and end date (END_DATE_TIME, if exists) and (ii) there is no end time on the recurrence (RECURRENCE_END_DATE) (i.e. it is an infinite event. Note that we can also define the occurrences count for an event.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 14
The FEEDBACK_ID will be set with the value of 1 (Requires Feedback: The agenda item requires to be accepted/rejected or put tentative) and can be set to 2 (Accepted: The agenda item has been accepted), 3(Rejected: The agenda item has been rejected. It will be maintained for archive purposes) or 4(Tentative: The agenda item has been put as tentative and will be brought up again for acceptance or rejection) according to the user feedback.
D4.1.a - Design and specification of ICT-based services and safety services
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 16
2.2 Care and Wellness – Medication Service
The medication service provides medical information related to a specific elderly. In
particular, this service is responsible for providing personal details of medicine associated
with an elderly such as name, description and route of medicine; along with medication
details such as date that an elderly started and ended a particular medication as well as
frequency that a medication should be taken.
The caregiver is responsible to insert/delete/update medication information for a specific elderly in the medication service. The medication information includes details regarding the medicine associated to an elderly, frequency that the medication should be taken and the medication route. In cases where new medication information is added then the medication service automatically creates a new calendar item through the agenda daemon of the Agenda Service. This calendar item will subsequently create a new agenda item (for more details see Section 2.1). Then the avatar, which will periodically check the agenda and notifications will remind the elderly to take his medication. The elderly can also view his/her medication list and details about each medication that s/he is associated to.
2.2.1 Use Cases
Medication Service
Create Medication for Elderly
Elderly
Manage Medication
Caregiver
Update Medication for
Elderly
Delete Medication for Elderly
<<include>>
<<include>><<include>>
<<include>>
Agenda Daemon
View Medication
Agenda Service
Figure 7 - Medication Service Manage Medication Scenario
The scenario of Figure 7 shows a caregiver that utilizes the medication service to manage medications. In particular a caregiver is able to create/update/delete medication details for a particular elder and views all medication information stored in the database. An elder is just able to do the latter action, i.e., view medication information. Each time a new medication is created, deleted or updated the agenda daemon is automatically invoked to update the agenda of the elder.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 17
Notification Service
Notification Daemon
Query for Active Medication
Medication Service
Figure 8 - Medication Service Medication Notification Scenario
In Figure 8, the medication notification daemon is periodically invoked to check for active medications assigned to particular elderly and sends notifications accordingly.
2.2.2 Database Design
Figure 9 presents the Entity Relationship (ER) schema of the Medication service that is included in the Care and Wellness database schema. All the tables currently included in this database are described in Table 3.
Similarly to the Agenda Service described earlier, in order to protect the structure and data of the base tables, we have implemented the VIEW_PERSON_MEDICATION and VIEW_MEDICINE view structures that provide all data required by the Care and Wellness methods.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 18
Table Name Description
CareWellness.MEDICINE This table stores information about a MEDICINE that can be assigned to an edler such as the name, route that should be followed and description.
CareWellness.PERSON_MEDICATION
This table stores information regarding the association between a medicine and an elder. In particular, it provides information of what medicine is assigned to a specific elder, date medication started, dose, frequency and date to end.
CareWellness.MEDICINE_FREQUENCY
This table stores the different frequencies regarding medications in general (e.g., once a day, once a week, etc.) Each frequency is assigned to a specific medicine.
CareWellness.MEDICINE_ROUTE This table stores the different routes regarding medications in general (e.g., injecting, oral, etc.) Each route is assigned to a specific medicine.
Table 3 – Care and Wellness Medication Database Tables
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 19
2.2.3 Methods Description
The Care and Wellness Medication service in order to achieve the functionality referred above will provide the following methods:
Method Name Description
LIST_MEDICINE Retrieves a list of all Medicine objects from table MEDICINE.
LIST_MEDICINE_FREQUENCY Retrieves a list of all MedicineFrequency objects from table MEDICINE_FREQUENCY.
LIST_MEDICINE_ROUTE Retrieves a list of all MedicineRoute objects from table MEDICINE_ROUTE.
DELETE_MEDICINE Deletes an existing record from table MEDICINE
DELETE_MEDICINE_FREQUENCY Deletes an existing record from table MEDICINE_FREQUENCY
DELETE_MEDICINE_ROUTE Deletes an existing record from table MEDICINE_ROUTE
DELETE_PERSON_MEDICATION Deletes an existing record from table PERSON_MEDICATION
GET_MEDICINE Retrieves a Medicine object.
GET_MEDICINE_FREQUENCY Retrieves a MedicineFrequency object.
GET_MEDICINE_ROUTE Retrieves a MedicineRoute object.
GET_PERSON_MEDICATION Retrieves a PersonMedication object.
GET_PERSON_MEDICATIONS Retrieves a list of PersonMedication objects.
GET_PERSON_ACTIVE_MEDICATIONS Retrieves a list of PersonMedication objects that are active for an elder.
INSERT_MEDICINE Inserts a new record into table MEDICINE
INSERT_MEDICINE_FREQUENCY Inserts a new record into table MEDICINE_FREQUENCY
INSERT_MEDICINE_ROUTE Inserts a new record into table MEDICINE_ROUTE
INSERT_PERSON_MEDICATION Inserts a new record into table PERSON_MEDICATION
UPDATE_MEDICINE Updates an existing record from table MEDICINE
UPDATE_MEDICINE_FREQUENCY Updates an existing record from table MEDICINE_FREQUENCY
UPDATE_MEDICINE_ROUTE Updates an existing record from table MEDICINE_ROUTE
UPDATE_PERSON_MEDICATION Updates an existing record from table PERSON_MEDICATION
Table 4 - Care and Wellness Agenda Service Methods Description
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 20
2.3 Guidance – Object Location Assistance
This service serves as a “memory support” that helps the elderly to remember where certain objects (e.g., wallet, keys) are usually stored around the house (e.g., in the kitchen drawer). This functionality can be used either for locating an object at runtime and providing location information or simply by informing the user of where he typically places his personal object. A high-level component interaction diagram is illustrated in Figure 10 – .
Guidance – Object Location Assistance
KnowledgeBase Service
Context Analysis (WP2)
«uses»Runtime Object
Tracking
Object Recognition
Typical Object
Locations
ObjectElderly
Search for Object location Monitors
Typical Object Location
Assistance
«uses»
«uses»
Elderly
Save object typical location
Figure 10 – Object Location Assistance Service Interaction Diagram
2.3.1 Use cases
Figure 11 illustrates a use case scenario where the elderly stores the typical location of an already saved object in the knowledgebase. The user defines the object name, the typical storage location and keywords for searching for this object in the future. The inputs can be verbally expressed or manually entered via the touch user interface. This also creates a correlation between a person and his personal items.
Object Location Assistance Service KnowledgeBase Service
Store ObjectTypical Location <<extend>>
Elderly
Store Object
Figure 11 - Elderly stores object typical location Use Case.
Figure 12 illustrates a use case scenario where the elderly manages the details of an object. More specifically, the user updates the details of an object (i.e., selects a previously stored object and modifies its details (i.e., name, storage location, search keywords), deletes an object (i.e., selects a previously stored object and removes it from the system). Additionally, the user can view a list of all its personal Objects (i.e., name, storage location, search keywords). All functionality is provided with collaboration with the KnowledgeBase Service, which stores information about all objects in the system.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 21
Object Location Assistance Service
KnowledgeBase Service
List Personal Object <<include>>
Elderly
Update Personal Object Details
Update Personal Object Location
Delete Personal Object Details
<<extend>> Manage Objects
Views Objects
Delete Object
Update object
Create Object
<<include>>
<<inclu
de>>
Figure 12 - Elderly manages object details Use Case
Figure 13 illustrates a use case scenario where the elderly queries for the location of an object. The user can select from a list or use a keyword to search for the stored object. If the object is found in the system then provides the object details and its typical location. The system will first search using real-time Object tracking as certain objects in the user’s environment may be tracked in real time with the use of cameras (e.g., Microsoft’s Kinect or other sensors). If the system track the object then it will query the KnowledgeBase service for its typical location stored.
Object Location Assistance Service
KnowledgeBase Service
Query specific Object from list
<<include>>
Elderly
Query for Person Objects
Query specific Object by keyword
<<extend>>
Query for object location
<<extend>>
Runtime Detection
Query for Person
Objects
<<include>>
Figure 13 - Elderly queries for object details Use Case
2.3.2 Database Design
Figure 14 illustrates the current database design of the Object Location Assistance Service. The database schema presents the Entity Relationship (ER) schema of the Object Location Assistance service included in the Guidance schema and its interaction with KnowledgeBase and Monitoring. All the tables currently included in this database are described in Table 5.
However, for more details about the attributes included in each table as well as the type and the description of these attributes please refer to Appendix A.
Table Name Description
KnowledgeBase.OBJECT This table stores information about an object.
KnowledgeBase.OBJECT This table stores information about the object type that an object belongs to object. Note, for the ObjectLocationAssistance the
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 22
predominant object type utilized is the Personal Items/Accessories.
Guidance.OBJECT_KEYWORDS This table stores information about the keywords that are linked with an object.
KnowledgeBase.PERSON This table stores information about a person (refer to D4.2 for more details)
KnowledgeBase.PERSON_OBJECTS This table correlates an object with a person.
In order to protect the structure and data of the base tables, we have implemented the VIEW_OBJECTS view structure that provides all data required by the Object Location Assistance methods.
D4.1.a - Design and specification of ICT-based services and safety services
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 25
2.4 Education/Leisure – Event Service
This section details the Event Service of the Education/Leisure Service. This service is mainly responsible to provide information about events so that the elderly can participate. This service starts with the caregivers adding and managing possible events and then the elderly view these events and decide if they want to participate. Immediately after this, the accepted event creates a new calendar event in the elderly’s agenda.
2.4.1 Use cases
In this section, two use case diagrams regarding the event service are presented and described.
Event Service
Caregiver
Elderly
Manage Events
Views Events
Delete Event Update Event
Create Event
Figure 15: Event Service Manage Events Use Case Diagram
Figure 15 shows a use case scenario of caregiver that utilizes the event service to manage - create/update/delete an event or that views all existing events. An elder on the other hand is able to just view all existing events.
Event Service
Elderly
Views Events
Participate in Event
Insert Calendar
<<extend>>
Agenda Service
Figure 16 – Event Service Elderly Decides to Participate to an Event Scenario
In the use case scenario illustrated in Figure 16 an elder requests to view all existing events in order to decide whether to participate or not. If an elder decides to participate in an event then the agenda service is automatically invoked and a calendar item is created.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 26
2.4.2 Database Design
Figure 17 presents the Entity Relationship (ER) schema of the Event service that is included in the Education\Leisure database schema. All the tables currently included in this database are described in Table 7.
NAME DESCRIPTION INDOOR_OUTDOOR DAY_NIGHT PRECAUTIONS ACTIVITY_ASSISTANCE
Figure 17: Education/Leisure Event Services Database ER schema
Table Name Description
EducationLeisure.EVENT This table stores information about the Events of an elder that decided to participate. It contains information regarding the start and end, the duration and the location of an event
Table 7 – Education\Leisure Event Database Tables
2.4.3 Methods Description
The Education/Leisure Event services in order to achieve the functionality referred above will provide the services shown in Table 8.
Method Name Description
KnowledgeBase
Education/Leisure
Monitoring
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 27
LIST_EVENTS Retrieves a list of all Event objects from table EVENTS.
INSERT_EVENT_WITH_LOCATION Inserts a new event record with location details into table EVENTS.
INSERT_EVENT Inserts a new event record into table EVENTS.
DELETE_EVENT Deletes an existing record from table EVENTS.
GET_EVENT Retrieves an Event object.
GET_DAILY_EVENTS Retrieves a list with Event objects for the current day.
GET_WEEKLY_EVENTS Retrieves a list with Event objects for the current week.
GET_MONTHLY_EVENTS Retrieves a list with Event objects for the current month.
GET_EVENTS_BY_START_END_DATE Retrieves a list with Event objects for a particular date range.
UPDATE_EVENT_WITH_LOCATION Updates an existing record from table EVENTS by deleting the existing record and creating a new updating at the same time the location information associated to it
UPDATE_EVENT Updates an existing record from table EVENTS by deleting the existing record and creating a new
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 28
3 Safety services
The development of safety services will fulfil safety needs of the elder in carrying out his/her daily life activities at home. These services can roughly be grouped in the two categories of (1) the Monitoring/Tracking services to detect a situation to which the system should react to, and (2) the Alert/Notification/Warning services to attend to the user to communicate and fulfil the safety needs.
3.1 Monitoring/Tracking Services
The groups of monitoring and tracking services are meant to continuously monitor the user and the surrounding to detect a situation in which a safety concern arises. Some services have been mentioned in the Description of Work (DoW) and others have been identified in the end-user needs analysis questionnaire of WP1, i.e.:
Establish a video or telephone conversation
Danger situations adviser
Dangerous objects adviser
Fall Detection
Continuous user location tracking
Turn off devices reminders
Entry points monitoring (theft awareness)
Mistaken fire alarm trigger
Some of these services – although their usefulness is not questioned – have been identified as out of scope of this project, i.e., the last two services: “Entry points monitoring” and “Mistaken fire alarm trigger”. Others are only used as part of another service to be marked as safety service, i.e., the service to establish a video or telephone conversation can be used by the fall detection service to alert a caregiver; therefore it is part of the safety service “fall detection”.
For the first version, only the fall detection service will be implemented.
3.2 Monitoring/Tracking - Fall Detection Service
Fall detection is probably one of the most famous and prominent services in the AAL domain. According to the Centers for Disease Control and Prevention, one out of three older adults, with an age of 65 or older, falls each year. For this focus group, falls are the leading cause of both fatal and nonfatal injuries. Therefore, systems that detect falls have been of increasing interest in the research community.
The typical scenario is as follows: if the system detects a fall, a telephone or video conversation with a caregiver is established to verify that a fall has occurred and that help is needed. In that case, either the caregiver can provide help directly, e.g., a by a near-by living relative, or an emergency number can be called.
By using depth-camera based low-level interpretations of the user and the environment in Task 2.2, the classical fall detection scenarios can be improved by adding information from
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 29
the surrounding, because the system can determine if the user is e.g., lying on the ground or on the couch and if he is only sleeping or really fall down.
3.2.1 Component Interaction Diagram
The fall detection service continuously monitors the user. To increase the robustness of detecting a fall, the virtual reconstruction of the surrounding from Task 2.2 is taken into account. If a fall is detected, the list of Emergency Contacts (as well as their telephone numbers or Skype information) is queried from Co-Net (though the use of Co-Net’s Virtual Care Team Management Service) and a telephone or video conference is started with the first entry in the contact list. If a contact cannot help, a call with the next contact in the list is initiated.
The list of Emergency contacts is managed by an administrator, through the use of Co-Net’s Virtual Care Team Management service, who allows him to perform queries (i.e., retrieve the members), or even add and remove contacts (members) from the user’s Virtual Care Teams. Note that currently, Co-Net supports five types of Virtual Care Teams. These are the Care Professionals, Friends, Family, Neighbours, and Emergency Contacts. Throughout the lifetime of the system new custom virtual care team types will be allowed to be created if needed.
More information regarding the Virtual Care Team Management service, describing in more details all the tables and methods currently supported by this service can be found in Deliverable D4.2 “Specification of Co-Net”.
Safety Services
Co-Net
«uses»«uses»
Context Analysis (WP2)
«uses»Fall Detection Object
Detection
VCT Service
Telephone Component
Elderly
Caregiver, Friends,
Family, etc.
CreateCall
Figure 18 – Component Interaction diagram for Fall Detection Service
3.2.2 Database Design
In this section, we provide the current database design of the Fall Detection services. Figure 19 presents the Entity Relationship (ER) schema of the Fall Detection service included in the safety service schema and its interaction with the Co-Net’s Virtual Care Team Management service database. All the tables currently included in this database are described in Table 9. However, for more details about the attributes included in each table as well as the type and the description of these attributes please refer to Appendix A.
Attribute Type Description
Column A (PK) Integer Column Desc
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 30
Column B (FK) Nvarchar(100) Column Desc
Table 9 - Monitoring/Tracking- Fall Detection Service Methods Description
Figure 19 - Monitoring/Tracking Services Database ER schema
Safety Service
DB Schema
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 31
4 Conclusions / Further Work
In this first version of deliverable D4.1 (D4.1a) we provide technical details regarding the design and implementation of a set of Home ICT-based services and safety services. In particular, we have designed and implemented the Care and Wellness - Agenda service that is responsible to keep track certain activities related to an elder, the Care and Wellness - Medication Service that provides medical information related to a specific elderly and the Education & Leisure - Event service that allows a user to invite other members to participate in group leisure activities.
The functionality of these services has been identified by taking into consideration the initial requirements and needs of the end users inferred from the first versions of D1.1a and D1.2a developed in WP1. Note that both the Home ICT-based services and the Safety services are expected to continuously evolve, thought out the lifetime of the project, according to the changing needs and requirements of the end users and the other related stakeholders and also the supporting functionality (if any) that the other components of the Miraculous-Life system will demand from the ICT-based and safety services. These changes/enhancements will be described in the second version of this deliverable (D4.1b) which is due to month 24 of the project.
Specifically, the second version D4.1b will include new ICT-based and safety services that will greatly enhance the functionality provided by the Miraculous-Life system: these services include, but not limited to, enhanced object recognition, activity services (i.e., gestures, actions), monitoring services, the household adviser as well as a number of group leisure activities.
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 32
Appendix A Data Dictionary
Below the tables included in the Agenda, Care and Wellness and EducationLeisure Service and supporting tables are presented.
A.1. Agenda Services
Schema Table Field Data Type Max Length
Precision Scale Primary Key
Identity Nullable Computed Description
Agenda PERSON_AGENDA
AGENDA_ID
udt_id 4 10 0 1 1 0 0 PK (Autonumber)
Agenda PERSON_AGENDA
ACTIVITY_ID
udt_id 4 10 0 0 0 1 0 FK - ACTIVITY
Agenda PERSON_AGENDA
CALENDAR_ID
udt_id 4 10 0 0 0 0 0 FK - PERSON_CALENDAR
Agenda PERSON_AGENDA
CALENDAR_TYPE_ID
udt_id 4 10 0 0 0 0 0 FK - PERSON_CALENDAR_TYPE
Agenda PERSON_AGENDA
DESCRIPTION
udt_description
MAX 0 0 0 0 0 0 Description of the Record
Agenda PERSON_AGENDA
END_DATE_TIME
datetime 8 23 3 0 0 0 0 The end datetime of the Record
Agenda PERSON_AGENDA
FEEDBACK_ID
udt_id 4 10 0 0 0 0 0 FK - PERSON_AGENDA_ACTION
Agenda PERSON_AGENDA
LOCATION_ID
udt_id 4 10 0 0 0 1 0 FK - LOCATION
Agenda PERSON_AGENDA
PERSON_ID
udt_id 4 10 0 0 0 0 0 FK - PERSON
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 33
Agenda PERSON_AGENDA
REMINDER_TIME
int 4 10 0 0 0 0 0 Reminder time in minutes (negative values: notification before event)
Agenda PERSON_AGENDA
START_DATE_TIME
datetime 8 23 3 0 0 0 0 The start datetime of the Record
Agenda PERSON_AGENDA_FEEDBACK
FEEDBACK_ID
udt_id 4 10 0 1 1 0 0 PK (Autonumber)
Agenda PERSON_AGENDA_FEEDBACK
DESCRIPTION
udt_description
MAX 0 0 0 0 0 0 Description of the Record
Agenda PERSON_AGENDA_FEEDBACK
NAME udt_name 400 0 0 0 0 0 0 Display name of the Record
Agenda PERSON_CALENDAR
CALENDAR_ID
udt_id 4 10 0 1 1 0 0 PK (Autonumber)
Agenda PERSON_CALENDAR
ACTIVITY_ID
udt_id 4 10 0 0 0 1 0 FK - ACTIVITY
Agenda PERSON_CALENDAR
CALENDAR_TYPE_ID
udt_id 4 10 0 0 0 0 0 FK - PERSON_CALENDAR_TYPE
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 34
Agenda PERSON_CALENDAR
DAY_FREQUENCY
int 4 10 0 0 0 1 0 An integer value for the frequency, i.e. 1 means “every occurrence”, 2 means “every second”, 3 “every third”, etc.
Agenda PERSON_CALENDAR
DESCRIPTION
udt_description
MAX 0 0 0 0 0 0 Description of the Record
Agenda PERSON_CALENDAR
END_DATE_TIME
datetime 8 23 3 0 0 1 0 The end datetime of the Calendar
Agenda PERSON_CALENDAR
EXACT_DAY
int 4 10 0 0 0 1 0 A specific day of the month.
Agenda PERSON_CALENDAR
EXACT_WEEK
int 4 10 0 0 0 1 0 A specific ISO week of the year
Agenda PERSON_CALENDAR
LOCATION_ID
udt_id 4 10 0 0 0 1 0 FK - LOCATION
Agenda PERSON_CALENDAR
MONTH_FREQUENCY
int 4 10 0 0 0 0 0 Month frequency
Agenda PERSON_CALENDAR
MONTH_PATTERN
int 4 10 0 0 0 0 0 Works like the weekday pattern, a binary, additive pattern that defines which months to
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 35
include: 1 January, 2 Frebruary, 4 March, 8 April, 16 May, 32 June, 64 July, 128 August, 256 September, 512 October, 1024 November, 2048 December
Agenda PERSON_CALENDAR
OCCURRENCES
int 4 10 0 0 0 1 0 The maximum number of occurrences. This parameter can be used with or instead of the END_DATE_TIME.
Agenda PERSON_CALENDAR
OCCURRENCE_NO
int 4 10 0 0 0 1 0 A specific occurrence. 0 The last occurrence..., 1 The first occurrence..., 2 The second occurence..., ... etc
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 36
Agenda PERSON_CALENDAR
OCCURRENCE_TYPE
int 4 10 0 0 0 1 0 How occurrences are grouped (partitioned) 1 ... of the week, 2 ... of the month, 3 ... of the year
Agenda PERSON_CALENDAR
PERSON_ID
udt_id 4 10 0 0 0 0 0 FK - PERSON
Agenda PERSON_CALENDAR
RECURRENCE_END_DATE
date 3 10 0 0 0 1 0 The end datetime of the Recurrence
Agenda PERSON_CALENDAR
REMINDER_TIME
int 4 10 0 0 0 0 0 Reminder time in minutes (negative values: notification before event)
Agenda PERSON_CALENDAR
START_DATE_TIME
datetime 8 23 3 0 0 0 0 The start datetime of the Calendar
D4.1.a - Design and specification of ICT-based services and safety services
Confidential Miraculous-Life 37
Agenda PERSON_CALENDAR
WEEK_DAY_PATTERN
int 4 10 0 0 0 0 0 A bitwise pattern for which weekdays to return. You can add these together, so 1+8+32=41 means mondays, thursdays and saturdays. (1 Mondays, 2 Tuesdays, 4 Wednesdays, 8 Thursdays, 16 Fridays, 32 Saturdays, 64 Sundays)
Agenda PERSON_CALENDAR
WEEK_FREQUENCY
int 4 10 0 0 0 0 0 Week frequency
Agenda PERSON_CALENDAR
YEAR_FREQUENCY
int 4 10 0 0 0 0 0 Year frequency
Agenda PERSON_CALENDAR_TYPE
CALENDAR_TYPE_ID
udt_id 4 10 0 1 1 0 0 PK (Autonumber)
Agenda PERSON_CALENDAR_TYPE
DESCRIPTION
udt_description
MAX 0 0 0 0 0 0 Description of the Record
Agenda PERSON_CALENDAR_TYPE
NAME udt_name 400 0 0 0 0 0 0 Display name of the Record
D4.1.a - Design and specification of ICT-based services and safety services
Description: Updates an existing record from table EVENTS by deleting the existing record and creating a new updating at the same time the location information associated to it
