Oasis – Open architecture for Accessible Services Integration and Standardization

1. 
   Context of use (aim)
   

2. 
   Primary actor
   

√ Elderly (ages 65-75)

 Old elderly (ages 75+)

3. 
   Secondary actor(s)
   

Informal care-givers (i.e. volunteers, neighbours, etc.)

Formal care-givers (both inpatient and outpatient)

Public / private Social security service providers and insurance companies

Service Centre

√Health care and emergency support service providers

Home automation service providers

√Leisure and re-creation service providers

Infotainment service providers

√Telematic service providers

√Elderly associations

National, local and regional authorities

Policy makers

 Other: …………………………………………………………….

4. 
   Connected UCs
   

5. 
   Priority Level
   

6. 
   Scenario(s)
   

7. 
   System output
   

Route guidance support during the whole trip and continuous monitoring for any emergency health problem: in case of a health problem detection, the system alerts the driver or performs a call to an emergency centered (imminent case), ensuring assistance to the driver.

8. 
   Relevant OASIS WP
   

9. 
   Services involved
   

Activity coach

Brain and Skills trainer

√ Social communities platform

√Health monitoring

Environmental Control

√Transport information

√Route guidance

√Driver telematic support

Driver comfort support

Tourism support

Leisure and social activities support

Smart workplaces

10. 
    Devices & restrictions
    

11. 
    Critical success parameters
    

12. 
    Environmental restrictions
    

13. 
    Interaction level
    

Step 2 – The user selects trip between bookmarked location (e.g. home, recreation centre) and a specific address or POI

Step 3 - The system asks the user whether to use the bookmarked routing options or to insert manually the following preferences:

• 
  Mean of transport (PT, car, pedestrian)
  
• 
  Arrival/starting time
  
• 
  Route optimization type (shortest, fastest, calmest)
  
• 
  Maximum walking distance
  
• 
  Maximum number of changes
  

Step 5 – the user requests information about colleagues (static o dynamic).

Step 6 – the system shows it in the corresponding device.

Step 7 – the user requests to store information about planned tasks, colleagues, and notes or related to the previously showed.

Step 8 – the system stores information on the user’s device.

Step 9 – the user asks for pre-defined route guidance and selects the elderly-friendly option.

Step 10 - the system provides point-by-point guidance.

Step 11 – The user has decided that he/she wants to stop to a specific place and wants to see parking availability. He/she has to configure (pre-configured values can be used) the maximum acceptable walking distance/time, price, etc.

Step 12: the system shows a list of parking places available. They can also be displayed on the map, referenced the current position.

Step 13: The user chooses one of the available options.

Step 14: the system guides the user to the parking.

Step 15 – The user would like to check his/her own health conditions and asks the system for help.

Step 16 – The in-vehicle system transmits the data read from the sensors worn by the driver to the health care centre.

Step 17 – The health care centre sends a response to the in-vehicle system.

Step 18 – The service centre delivers the response to the user.

14. 
    Personalisation/ adaptation level
    

static parameters: static user profile (i.e.: name, date of birth, etc.)

semi-dynamic parameters: type of user, user’s case history and medical data (i.e.: known pathologies, allergies, etc.)

dynamic parameters: maximum walking distance/time accepted, maximum price accepted, current values of the user’s health parameters acquired by the wearable sensors

environmental parameters/context of use: weather forecast, day and hour (to check parking opening/closing time/date)

15. 
    Quality of service indicators
    

Return of route < 5min

Time demands: the new route does not enhance the overall journey time over …% (could be pre-selected or defined by the elderly user him/herself, as an option).

Reliability/accuracy demands: as a ‘standard’ navigation system. Recommendations of the Driving Group eCall, concerning:

• 
  percentage of the triggered emergency calls that reach the mobile network operator;
  
• 
  percentage of the activated emergency calls that reach the emergency centre (forwarded by the network operator);
  
• 
  latency of intervention.
  

16. 
    Potential input needed from other UCs (what input and which UCs?)
    

Bookmarked POIs or places should be available from UC SP3-18 “Bookmark POI”.

The destination/current position has to be provided to the service centre to initiate a parking search.

The list of parking places has to be provided from the POI database, and additional information from a Service provider.

Information on the user’s vital parameters acquired by the body sensor system of Personal mobility UC1 (Driver/passenger health assistant in critical conditions) could be sent together with the data pertaining to the present UC to the emergency centre.

17. 
    Important accessibility attributes (per UG)
    

The health monitoring and alerting/emergency functions must be always available and working.

User’s profile and medical profile must be considered in order not to trigger warnings unnecessarily.

18. 
    Background info/ reason on selection and on assigning the priority level
    

19. 
    References
    

20. 
    Comments