Apollon - Homecare and Well-Being - Cross Border Living Lab Set-up

DELIVERABLE

Project Acronym:

APOLLON

Grant Agreement number:

250516

Project Title:

Advanced Pilots of Living Labs Operating in Networks

D2.3 Set-up of local experiment in the remote Living Labs

Revision: Final

Authors: Daan Velthausz (AIM) Bidatzi Marín (IAV) Montserrat Dominguez (IAV) Tim van den Dool (INN) Marianne Dannbom (FVH) Bram Lievens (IBB) Hendrik Hielkema (AALTO) Saar De Zutter (Televic Healthcare N.V.)

Project co-funded by the European Commission within the ICT Policy Support Programme Dissemination Level P

Public

C

Confidential, only for members of the consortium and the Commission Services

X

Apollon – Deliverable 2.3

Revision History Revision Date

Author

Organisation

Description

0.1

Daan Velthausz

AIM

Initial draft, structure

0.2

Daan Velthausz

AIM

Restructuring according to Malaga workshop

0.3

06/2011 Marianne Dannbom

FVH

Xtramira pilot in Helsinki

Saar De Zutter 0.4

0.5

0.6

1.0

08/2011 Bram Lievens

TLV IBBT

Bidatzi Marin

IAV

Hendrik Hielkema

Aalto

10/2011 Tim den Dool

INN

Bidatzi Marin

IAV

Daan Velthausz

AIM

Saar de Zutter

TLV

Tim den Dool

INN

Marianne Dannbom

FVH

Bram Lievens

IBBT

Bidatzi Marin

IAV

Hendrik Hielkema

Aalto

Daan Velthausz

AIM

Koen De Vos

IBB

1/2012

2/2012

Updates pilots

Updates pilots, and finals edits

Update review comments

Finalization

The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.

Statement of originality:

This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

ICT PSP Project Reporting Template

2

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 Table of Contents 1. Introduction ................................................................................................................ 4 2. Research set-­‐up of the pilots ................................................................................. 6 2.1 Xtramira Case ................................................................................................................ 8 2.2 Innoviting Case ............................................................................................................... 13 3. Operational pilot aspects ...................................................................................... 17 3.1 Xtramira Case data .................................................................................................... 17 3.1.1 In depth interviews ................................................................................................................ 17 3.1.2 Questionnaire ............................................................................................................................ 18 3.1.3 Logging ......................................................................................................................................... 20 3.1.4 Data Analysis ............................................................................................................................. 20 3.1.5 Organisational aspects .......................................................................................................... 21 3.2 Innoviting Case ............................................................................................................... 22 3.2.1 In depth interviews ................................................................................................................ 22 3.2.2 Questionnaire ............................................................................................................................ 23 3.2.3 Logging ......................................................................................................................................... 23 3.2.4 Data Analysis ............................................................................................................................. 24 3.2.5 Organisational aspects .......................................................................................................... 24 4. Technical pilot aspects .......................................................................................... 25 4.1 Xtramira Case .............................................................................................................. 25 4.2 Innoviting Case ............................................................................................................... 26 4.3 Conclusions ...................................................................................................................... 28 5. Crossborder research goals ................................................................................. 29 6. Crossborder lessons learned up till now ......................................................... 34 6.1 The Xtramira case ..................................................................................................... 34 6.2 The Innoviting case ....................................................................................................... 37 6.3 General conclusions ...................................................................................................... 38 References ......................................................................................................................... 40

ICT PSP Project Reporting Template

3

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

1. Introduction As stated in the Description of Work Document (DoW) and in Deliverable 2.2 of this Work Package (“Common Approach”), Work Package 2 within APOLLON, clusters four Living Labs that focus on Health and well-­‐being related solutions.

Two Independent Living Systems (ILS) are to be transferred and piloted a sending living lab to a receiving living lab. Figure 1 illustrates the relationships and flow between the different tasks and deliverables in Work Package 2.

Figure 1. Relationship between tasks and deliverables of Work Package 2

Task 2.2 deals with the actual deployment and set-­‐up of the experiments in the receiving living labs (Finland and Spain). Task 2.3 comprises the cross-­‐border piloting dimensions of the experiments, whilst which Task 2.4 will cover the evaluation and recommendation activities.

Deliverable 2.2. provided the common approach for the research, data gathering and data analysis activities that takes place during Task 2.3 of Work Package 2.

Task 2.3: -­‐

determines the measurements that need to be undertaken during the experiment on location. These measures are based on the requirements as set in task 2.4 “Evaluation”

-­‐

develops a plan how measurements will take place during the experiments.

These measurements will be based on the work in WP1 and will take the setup description of Deliverable 2.2 as a starting point.

-­‐

monitors the execution of the experiments and measurements

ICT PSP Project Reporting Template

4

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 The final measurement data after the experiment will be used in task 2.4.

This document, Deliverable 2.3, provides the actual and detailed setup of the experiments at M12 of the project -­‐ as to be performed in the Living Labs. It also define the transfer strategy, technical recommendations and protocol between the different Living Labs.

To achieve this result the following activities were performed: -­‐

Based on Deliverable 2.1 and product/service data it has been investigated where the best information on use, usage and user experience can be found, and how this data can be measured (technical, logging, interviews, workshop). These measurements relate to first order effects (in the product or service) and second order effects (for the Living Lab).

-­‐

Discussions with the partners, with a focus on what is needed from an organisational/operational level and to be adapted for task 2.4.

-­‐

Report on the measurement and operation of the experiment reflected in this document (Deliverable 2.3). Part of this deliverable is also an operational plan for the management of the measurements and execution of the experiments. This is aligned with the specifications as provided by WP1.

Input used from Deliverable D2.1 and D2.2: -­‐

Televic and Innovating: clear descriptions of their product/service

-­‐

Forum Virium and iAvante for a clear description of the living lab setting

This document is divided in a description on pilot level (sections 2-­‐4) and on the cross border level (sections 5-­‐6).

On the pilot level we will elaborate on three levels: •

Research (section 2)

•

Operational (section 3)

•

Technological (section 4)

In the cross border level we address the:

•

Research (section 5)

•

Lessons learned up till now (section 6)

ICT PSP Project Reporting Template

5

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

2. Research set-up of the pilots This section describes in detail the measurements needed in place to address the relevant questions related to research, data gathering and the subsequent analysis of it, as outlined in Deliverable 2.2 using the input from Workpackage 1, i.e. Deliverable 1.3.

The key research questions for the healthcare pilots include: 1. How to address the harmonization and interoperability challenge for this pilot (related to ecosystems)?

For what concerns interoperability – For the specific Homecare and Independent Living we will not focus on interoperability on a technical level but on a more contextual level. Especially in this specific domain, the eco-­‐ system is a very important and determined factor. It is not sufficient that a service or product can be transferred from a more technical point-­‐of-­‐view, it also has to fit in the local context. eHealth type of services and products are always embedded in a specific eco-­‐system (which is organized differently all over Europe). During the cross-­‐border activities we will investigate how we can be interoperable between the various eco-­‐systems. This is done by either involving additional partners that are necessary to complete the required eco-­‐system or through the Living Lab identifying the gaps in the required eco-­‐system.

2. How to demonstrate the value added of cross border networking of living labs?

In both cases (ILS and ADL) this is about implementing the right measurement instruments that will allow them to capture the impact of the provided solution on different levels: not only the user but for all stakeholders. Elements that will be subject of this are a.o. the efficiency (in time, cost, operations…), the quality of experience, assessment of new market opportunities, mapping the eco-­‐system.

For the ADL case, we also will be able to evaluate the impact on the current practices of the SME partner (assess their expansion possibilities abroad).

For both ILS (Xtramira by Televic in Belgium) and ADL (by Innoviting in the Netherlands) the Requirements Identification (D2.1) establishes the transferring Living Labs (IBBT and AIM) as the main supervisors to monitor the set-­‐up and research activities (Research coordination). The transferring Living Labs set-­‐up the research framework and provide the local Living Labs with questionnaires, topic lists for interviews, etc. The coordination of the local living labs will be steered by the transferring Living Labs but this will require a close cooperation and open dialogue between the partners.

The research set-­‐up that will be applied in the Living Labs is a people-­‐centered approach in which we will not only focus on the deployment of the service, but also investigate how various users experience the independent living systems (ILS) in their daily lives. These user groups are not only the end users, but in the

ICT PSP Project Reporting Template

6

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 Spanish case the relatives and others who are providing home-­‐care, in the Finnish case the investigation will include user groups such as the home care providing nurses, the Help desk staff and the management of the organizations that provide parts of the service.

According to Deliverable 1.2 (Research framework and investigation strategy), we can apply the Apollon research framework by answering the questions in each of the following classes illustrated in Table 1.

Table 1 Thematic experiments’ focus and content communicated in categories of ‘activities’.

Activities/

Build

Evaluate

Justify

Generalize

Eco-­‐system parameters for cross-­‐border piloting

User experience

Based on the experiences in the local experiment, assisted to the experience of the remote Living Lab

In each step we will look at (a) cross-­‐border aspects, (b) eHealth specific issues and (c) the eco-­‐system determinants

Transfer and deployment technology

Comparison of the different pilots, exchange with other eHealth Living Labs

Outputs Constructs

eHealth specific requirements for cross-­‐ border piloting (such as security, privacy, liability…)

Model

A transfer of an eHealth service or product has to be contextualized Local partners need to be involved to take up the different roles in the eco-­‐system

Impact on actors involved Collaboration between the partners Cross-­‐border specific issues Reporting 3 monthly assessment

New business opportunities

Interviews Questionnaires

In a cross-­‐border transfer the Living Lab will be more than just a facilitator. I t will have to take more responsibilities than in local pilots.

Method

Determine specific hypothesis related to the set-­‐up and process and assess them during and after the pilots

ICT PSP Project Reporting Template

Efficient procedures, tools and methods Identification of the required eco-­‐ system building blocks Strategy for a network of Living Labs

Through the three-­‐ monthly reporting and interaction with WP1

7

Based on the experiences in the local experiment, assisted to the experience of the remote Living Lab

Adjusting technology to be multi-­‐language, multi-­‐contextual and scalable for large roll-­‐out

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 Installation

Living Labs

Interviews

Local actors

Questionnaires

End-­‐users

Based on a. the eco-­‐system and b. scope of the project and c. the implementation limitations

Exchange lessons learned between partners, the consortium, other Living Labs.

Working towards a thematic network

The user research to be conducted by Work Package 2, as documented in D2.1, has very similar goals for both experiments. In Figure 2 the flow is visualized of this work packages, i.e. the different tasks and the research questions and applied approach for the two cases, and how in this is reflected in this Deliverable 2.3 (a result of tasks 2.3).

Figure 2: visualization of the research questions in the different tasks.

2.1 Xtramira Case The mentioned framework is tailored to the Xtramira case, and listed in Table 2.

Table 2: Apollon research framework populated for the Xtramira case.

Activities/

Build

Evaluate

ICT PSP Project Reporting Template

Justify

8

Generalize

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 Outputs Constructs

What are the variables that you study?

What are the elements that you measure?

The different elements of the health eco-­‐system that have an impact on cross-­‐border Living Lab projects

Every aspect of the setup of the pilot Procedures which is different The feasibility of an that can be from the setup in the harmonized eco-­‐system generalized Living Lab in and how this would across different Belgium is a pilot benefit SMEs in cross-­‐ setups can be specific element. The border activities defined as best most prevalent practices, for elements are those The potential of instance how that need a different creating new business to manage technical solution or research such as new security opportunities based on localization issues or the need the cross-­‐border aspect issues. for different The need and possible applications such as benefit of the thematic alarm only versus cross-­‐border network social functionality. of Living Labs

How can we harmonize the eco-­‐ system between Living Labs and make them interoperable.

Model

What are the basic assumptions, causalities and outcomes that you perceive?

The experience of the end-­‐users as the stakeholders

What measures do you use to evaluate the validity of the assumptions?

The feasibility of General basic creating a common eco-­‐ assumption is that system within every when in each of the Living Lab that is active Living Labs a similar in an eHealth network eco-­‐system is in Different factors of the place, the transfer ecosystem, such as or set-­‐up of cross-­‐ stakeholders and their border pilots will be roles, regulations and much faster, easier policies, and The assumptions ethical/social issues. made were related to the case specific setting and its requirements.

The expected outcome is a description of the relevant factors in a (e)Healthcare ecosystem.

How do you decide best practices across the experiments?

How do you filter pilot specific elements out?

What are the success criteria that you use?

How do you assess the wider applicability of the model?

The transfer of one technology from one context and eco-­‐system to another The identification of the various dimensions within an eco-­‐ system that have an impact

Useful guideline for health related cross-­‐ border pilots Exchange lessons learned, creating templates etc…

Comparison to the relevant ecosystem factors described in D2.5 which are part of the Belgian living lab.

The identification of the needs for a cross-­‐border network of living labs

ICT PSP Project Reporting Template

9

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 Method

What is the process for validating the assumptions?

Setting-­‐up the transfer Performing user research and stakeholder analysis Questionnaire with regard to network When setting up the actual pilot and discussing what is needed and which application would be most relevant for the remote living lab, the assumptions were one by one encountered and either confirmed or rejected.

Installation

Who are the stakeholders at your experiment?

Different actors that are required to establish the required eco-­‐ system: the City of Helsinki, the different partners (living lab, research institutes, SME), policy makers, network providers, different groups of end users from the living lab (specific profiles)

How do you evaluate and adjust the validation process?

How do you justify the use of selected methods?

How do you ensure the scalability and wider applicability of the methods?

Evaluation and adjustment on the level of the pilots is done ad-­‐hoc.

On the local level methods and processes are selected by the local Living labs based on their experience and way of operation

Practicality is still the most convincing method (in terms of use, installation, extra effort, cost,…)

How do you justify the selected collaboration model?

How do you compile recommendations for sustainability?

The lessons learned with regard to the eco-­‐ system and the underlying dimensions that are identified will be checked with other Living Labs

How do you evaluate added value for each stakeholder?

Based on interviews with the various stakeholders

Reshape lessons learned, practicals What seems to into templates that be most practical can be used widely (in terms of use, installation, extra effort, cost,…)

This is done based on the objectives, the specificities of the set-­‐up as well as the contextual elements

Manuals, local and remote test and validation environments Creation of processes and templates Identificatioon of useful tools and methods Generic eco-­‐system mapping

To get a better understanding of the research objectives of the pilot, the research goals and measurements for the Xtramira case are summarized in Table 3. These research goals are targeted on the pilot level in the first place. But they will enable us to address the generic research objectives in terms of the cross-­‐border aspects of Living Labs working in a network.

ICT PSP Project Reporting Template

10

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

Table 3: Research goals and measurements for the Xtramira case.

Research goal

Measured via

Responsible party

Contextual difference between the local and remote living lab

a) Place of the device/application in the services of the care organization

Social context for using the devices, communication between the end users in Helsinki, mostly communication with the desk of a care provider in Belgium

b) Type of users (attitudes, behavior and skills of users regarding independent living and technology)

IBBT has provided the topic lists, questionnaire and instructions to Aalto University and Forum Virium

The user experience of the device / applications

a) satisfaction level b) easy of use c) practices

Aalto University – based on the initial research conducted for the Flemish case

d) addressing their needs e) increased social contacts f) increased feeling of security The remote ecosystem and business opportunities for the ILS

a) the ecosystem

IBBT

b) amount of business potential

Forum Virium

The following stakeholders are involved in Xtramira experiment: Agents or stakeholders: •

•

End-­‐users: we will have 30 end-­‐users directly involved in the project (equipped with the technology). 10 are elderly people living at home, 20 are hearing impaired people1. In addition friends and relatives will be indirectly involved, they will be able to use a SIP Client on their own PC. (but will not be equipped with an Xtramira).

Local Living Lab: Forum Virium has a central role in setting up the test-­‐ project and as gateway to the local stakeholders.

Institutions: •

•

Telco / ISP: Within the projects cope we will use commercial available/existing connections. The ISP is therefore not directly participating.

SIP provider: The need to have an independent SIP provider was a result of the requirement analysis and the preparatory work. During the project

This is changed from the initial set-­‐up on request of the SME so they will also be able to test and evaluate their product on another potential segment of the market.

1

ICT PSP Project Reporting Template

11

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

•

•

• •

•

a dedicated SIP server will be hosted by a telco in Belgium in cooperation with Televic.

System integrators and installers: Forum Virium as the local Living Lab will act as the integrator and the local ecosystem of the pilot having a total responsibility of setting up the pilot: recruitment, installations, training etc.

Knowledge partners (universities, branch institutes): Aalto University will conduct the research and will immediately try to link up with existing, parallel pilots.

Local authorities, like city of Helsinki city granting the ethical approval etc.

Civic associations: the group of elderly people are involved in the volunteer work association in the Eastern part of Helsinki, one group of deaf people are from the Federation of Hard of Hearing.

Technology providers Internet broadband will be provided by local telecom providers as part of their normal offering.

In addition to the stakeholders and their roles mentioned above, additional aspects that are dealt with in the pilot are: Regulations, policies and legal requirements: • • • • • • •

Personal data protection and privacy laws Ethical board regulations and processes Patients rights laws Dependent people laws General healthcare laws Local (i.e. municipal / county) regulations Agreement between Apollon partners and end-­‐users (on good usage, expectations, commitments…)

Social interaction: • • • •

Communication and terminology Cultural issues Case specific requirements (functionalities) Case specific setting

Business Model: • • • • •

Financial prospects Market and product maturity Sustainability (manuals, knowledge transfer, training) Integration with other services Media

Operational issues: • • •

Translations and how to Software updates for extended logging and monitoring Organisation of remote support

ICT PSP Project Reporting Template

12

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

2.2 Innoviting Case The mentioned framework is tailored to the Innovating case, and listed in Table 4.

Table 4: Apollon research framework populated for the Innoviting case.

Activities/ Outputs

Build

Evaluate

Justify

Generalize

Constructs

What are the variables that you study?

What are the elements that you measure?

How do you filter pilot specific elements out?

Adequacy of the service to its stated purpose

User satisfaction

How do you decide best practices across the experiments?

SME evaluation

Effectiveness of the LL-­‐network model in cross-­‐ border transfer of services Model

What are the basic assumptions, causalities and outcomes that you perceive?

What measures do you use to evaluate the validity of the assumptions?

That the network is capable of catalyzing the cross-­‐border transfer

Interview with stakeholders involved

That the remote LL is capable of performing the localization work efficiently

Tracking of the development and deployment process

Internal Benchmarking within the WP

What are the success criteria that you use?

Executing the pilot as intended Adjusted solution deployed in the Living Lab

Basic Root Cause Analysis

How do you assess the wider applicability of the model?

Comparing with the results/outcomes of the piloting at the local living lab and by filtering pilot-­‐specific elements.

That the SME is capable of adapting re-­‐ focusing its solution to the new ecosystem

Method

What is the process How do you for validating the evaluate and assumptions? adjust the validation Real life pre-­‐ process? testing the adjusted service Efficiency and outcomes of the

ICT PSP Project Reporting Template

13

How do you justify the use of selected methods?

How do you ensure the scalability and wider applicability of the methods?

Previous experience

No specific scaling problem with the

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 Technical testing validation of the adjustments process System analysis and feedback meetings Installation

Who are the stakeholders at your experiment?

The group of end-­‐ users The involved family members and or informal care-­‐givers

How do you evaluate added value for each stakeholder?

Interviews Questionnaires Work-­‐meetings

The IAVANTE Foundation

Agility, adaptability and simplicity

used methods

How do you justify the selected collaboration model?

How do you compile recommendations for sustainability?

Based on the service and the context in which the service is being deployed

Documenting the implementation of the methods

Document the experience in public report Presenting lessons learned

SMEs (Innoviting) AIM The Andalusian Foundation for Social Services Telecom provider

To get a better understanding of the research objectives of the pilot, the research goals and measurements for the Innoviting case are summarized in Table 5.

ICT PSP Project Reporting Template

14

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

Table 5: Research goals and measurements for the Innoviting case.

Research goal

Measured via

Responsible party

The user experience of the device / applications

a) satisfaction level

INN and AIM provide the topic lists and questionnaires to IAV.

b) ease of use c) addressing their needs d) what functions are filling the needs of the elderly and the caregivers?

IAV executes the interviews, briefing meetings and general feedback process.

The remote ecosystem and business opportunities for the ILS.

a) amount of business potential

IAV

We want to be able to address the outcomes of the local experiment and enhance it at national level if possible, i.e. by generalizing findings for the specific region in south of Spain to country level of Spain.

a) the ecosystem analysis

IAV

The following stakeholders are involved in experiment: Agents or stakeholders: • • • • • •

Users Family members Care-­‐givers Neighbors Social services staff Emergency personnel

Institutions: • • • • • • • • • • •

Social services agencies Private social and health services providers Telco / ISP System integrators and installers Knowledge partners (universities, branch institutes) Insurance companies Local authorities Elderly residences Civic associations Emergency services Technology providers

ICT PSP Project Reporting Template

15

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 •

Related remote services

In addition to the stakeholders and their roles mentioned above, additional aspects that are dealt with in the pilot are: Regulations, policies and legal requirements: • • • • • •

Personal data protection and privacy laws Ethical board regulations and processes Patients rights laws Dependent people laws General healthcare laws Local (i.e. municipal / county) regulations

Social interaction: • • • •

Communication and terminology Cultural issues Case specific requirements (functionalities) Case specific setting

Business Model: • • • • •

Financial prospects Market and product maturity Sustainability Integration with other services Media

ICT PSP Project Reporting Template

16

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

3. Operational pilot aspects In Deliverable D2.2 the deployment plans for both pilot cases are described in generic terms. Here we provide more detailed information on the people and locations and stakeholders involved, including how we dealt with solving privacy issues. We describe the action plan and schedule for the activities that need to be executed for successful deployment of the experiments. The local Living Labs are responsible for the local deployment and execution of the research plan.

The deployment activities for each of the two pilots is described in this section.

3.1 Xtramira Case data

For the data collection we will use various methods: scripted and in-­‐dept interviews, both individual as well as focus group, survey and logging. The case data will be situated on two levels: on the one hand the pilot specific results and the outcomes on the cross-­‐border level (and further steps) on the other hand.

3.1.1 In depth interviews The goal of the in-­‐depth interviews is to get rich data about the main topics of this study. Interviews will be done with the following actors: -­‐

the responsible of the care organisation

-­‐

the operators / technicians

-­‐

the SMEs (Televic)

-­‐

the Large Enterprises, (Palmia, Elisa)

The topics for these interviews focus on the evaluation of both the deployment process and the service itself. Also we will discuss more on the business proposition of the solution as well the eco-­‐system in which this pilot is executed.

Here we will also focus on how to engage additional partners from the eco-­‐ system required for the cross-­‐border aspect. From the local Living Labs and current projects the used topic lists of the different interviews will act as a starting point.

The interviews will be conducted by Aalto University at the relevant moments during the actual deployment of the system. Table 6 below summaries these in-­‐ depth interviews to be conducted.

ICT PSP Project Reporting Template

17

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

Table 6 In depth interviews to be conducted for the Xtramira case.

Local living lab (Belgium)

Who is interviewed?

• • • •

Topic list interviews

the responsible of the care organization the desk operators two users the SME (Televic)

Different topic list (according to who is interviewed) (see attachment): • • •

topic list – representative public welfare organization topic list – the client topic list – desk operator

Remote living lab (Finland) • • • • •

project managers technical staff care providing staff the Users other involved people

The topic of discussion will be the relevant aspects of the service to the interview person.

Who conduct An IBBT researcher interviewed the interviews? the responsible of the care organization, the two users, and the social nurses (desk operators)

Aalto

How the interviews are analyzed?

Text analysis

Text analysis

Possible data mining

When and how Separate report the reporting is The report was handed over to done? the remote living lab and the local partners2

Separate reports on the Xtramira cases and the parallel pilots, Lessons learned will be embedded in D2.4

3.1.2 Questionnaire Within the user-­‐centered approach of the project it is necessary to have a good interaction with the different stakeholders for whom the end-­‐users are playing an important role. To collect the user feedback a small questionnaire will be used. The objective is that these interviews are conducted by the persons who already have close bonds with the users. The various groups of users may be approached in different manners, the elderly can be interviewed directly with a script, or provided assistance in completing the questionnaire, while the hearing

2 Due to company strategic reasons this report is not public available ICT PSP Project Reporting Template

18

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 impaired group is possibly better off using a paper or online questionnaire. In table 7, the scheduled interviews are listed.

This approach also allows us to investigate to what extent this method could be used in case of a large test population as it is more pragmatic and convenient.

Questionnaires are an often used method in Living Lab research. The results of these questionnaire will also provide input with regard on how to use this type of tools and methods in a cross-­‐border experiment.

Table 7 Interviews to be conducted for the Xtramira case.

Local living lab (Belgium)

Remote living lab (Finland)

Who is interviewed?

8 end-­‐users

Elderly people

Professional care-­‐givers

Hearing impaired people

All stakeholders (operator, Inner circle (relatives, family) local public welfare organization,…)

Who conducted the The operators (social interviews? nurse and social worker close to the end-­‐users)

Aalto University

How the interview takes place?

The various groups of users may be approached in different manners, the elderly can be interviewed directly with a script, or provided assistance in completing the questionnaire, while the hearing impaired group is possibly better off using a paper or online questionnaire.

By a structured questionnaire taken by the operators (for them specific training (oral and written instruction) was given to conduct good interviews

Where and when During a home visit the interview takes place?

Depending on the user preferences

How the interviews Text analysis are analyzed?

Text analysis and data mining of the logfiles

When and how the reporting is done?

Separate report produced by the IBBT Living Lab

Separate reports on the Xtramira cases and the Report was discussed with parallel pilots, the stakeholders Lessons learned will be

ICT PSP Project Reporting Template

19

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 Report was handed over reflected in D2.4 to the remote research organization (AALTO) and Living Lab (FV)

3.1.3 Logging It is important that we can match the results of the interviews with objective data of the real behavior of the service. The logging will be limited to non-­‐ contextual data such as the amount of use, the duration. Logging is a necessity for a better reporting and to provide a better understanding of the actual use of services and could be used for the optimization of the services through the analysis of certain patterns. The logging can be foreseen on the application, the device and on the network level. Within the project both services are a server-­‐ based solution. The logging will therefore only be foreseen on the server level.

Locally, when a PC is connected to the Xtramira device, several different logging options are available: • • • • • • •

audio and video traffic can be logged the SIP connection (the registration and SIP traffic) the Televic State Machine (to know which status the device is in, e.g. standby, calling,…) all sent and received DTMF tunes all configuration actions (e.g., updates, new phonebook contacts, …) all general purpose input and output (e.g., actions on the grey buttons of the device) All technical alarms made

Due to privacy issues, this logging data is only used for debugging purposes.

Before the launch of the pilot TELEVIC will perform a software upgrade in which more detailed logging and monitoring is being tracked. Currently this is still under development and not all features are known.

3.1.4 Data Analysis The evaluation of the cross-­‐border pilots will be done on the level of the pilot itself and on the level of the collaboration. The focus at pilot level will be on the methods used, the implementation as well as the gained results.

Analysis at pilot-­‐level: we will analyze the experiment specific data. The objective of this analysis is to evaluate the service with regard to the usage, experience, attitudes. Initially, logging data will be used. For each of the applications we will investigate the specific usage of the service (length, frequency). This data will generate certain hypotheses that will be checked with the data of the more qualitative research activities (interviews). The data sets will be analyzed using different actor perspectives: the end-­‐user, the professional user, the operator…

ICT PSP Project Reporting Template

20

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 3.1.5 Organisational aspects For setting up the Helsinki pilot the following steps will be taken: • • • • •

Analysis of the local experiment: looking at the different roles and responsibilities of each actor involved Investigating the remote eco-­‐system: which partners are needed to conduct the experiment Set-­‐up meetings between different (potential) stakeholders to check the expectations, the roles, way-­‐forward In-­‐house trial and demo Need to acquire permissions to be compliant with local rules and regulations

ICT PSP Project Reporting Template

21

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

3.2 Innoviting Case For the data collection we will use three methods: in depth interviews both individual as well as focus group, survey and logging.

3.2.1 In depth interviews The goal of the in-­‐depth interviews is to get rich data about the main topics of this study. Interviews will be done with the following actors: • • • •

the responsible of the care organisation the operators / technicians the users the SMEs

The topics within these interviews will focus on the evaluation of both the deployment process and the service itself. Also we will discuss more on the business proposition of the solution as well as towards the eco-­‐system in which this pilot is executed. From the local Living Labs and current projects the used topic lists of the different interviews will act as a starting point. See Table 8 below for the overview of the in-­‐depth interviews.

Table 8: In depth interviews to be conducted for the Innoviting case.

Local living lab (Netherlands)

Remote living lab (Spain)

Who is interviewed?

Users, caretakers

Users and family members

Topic list interviews

Demographics

Provided by INN

Current situation Problems / Needs Features / Price

Who conduct the interviews?

Students from the Hogeschool Utrecht

How the interviews Students from the Hogeschool are analyzed?

Utrecht When and how the reporting is done?

Seperate report

Personnel from IAV Pilot-­‐level discussion (AIM-­‐INN-­‐IAV) Separate report on the Innoviting cases Lessons learned will be embedded in D2.4

ICT PSP Project Reporting Template

22

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 3.2.2 Questionnaire Within the user-­‐centered approach of the project it is necessary to have a good interaction with the different stakeholders for whom the end-­‐users are playing an important role. To collect the user feedback a small questionnaire will be used. The objective is that these interviews are conducted by the persons who already have close bonds with the users. We will therefore hand them the questionnaire with some oral and written instructions. This approach also allows us to investigate to what extent this method could be used in case of a large test population as it is more pragmatic and convenient.

Table 10 Interviews to be conducted for the Innoviting case.

Local living (Netherlands)

lab Remote living lab (Spain)

Who is interviewed?

Users, caretakers

Family members / informal care-­‐givers

Who conducted the questionnaires?

Students from the Hogeschool Utrecht

Personnel from IAV

Where and when the interview takes place?

At different locations

IAV facilities in Malaga and Granada

How the interviews are Students from the analyzed?

Hogeschool Utrecht When and how the reporting is done?

Seperate report

Pilot-­‐level discussion (AIM-­‐INN-­‐IAV) Separate report on the Innoviting cases Lessons learned will be embedded in D2.4

3.2.3 Logging It is important that we can match the results of the interviews with objective data of the real behavior of the service. The logging will be limited to non-­‐ contextual data such as the amount of use, the duration… Logging is a necessity for a better reporting and to provide a better understanding of the actual use of services and could be used for the optimization of the services through the analysis of certain patterns. The logging can be foreseen on the application, the device and on the network level. Within the project both services are a server-­‐ based solution. The logging will therefore only be foreseen on the server level.

ICT PSP Project Reporting Template

23

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 3.2.4 Data Analysis The evaluation of the cross-­‐border pilots will be done on the level of the pilot itself and on the level of the collaboration. The focus at pilot level will be on the methods used, the implementation as well as the gained results. We will analyze the experiment specific data. The objective of this analysis is to evaluate the service with regard to the usage, experience, attitudes… Initially, logging data will be used. For each of the applications we will investigate the specific usage of the service (length, frequency…). This data will generate certain hypotheses that will be checked with the data of the more qualitative research activities (interviews…). The data sets will be analyzed using different actor perspectives: the end-­‐user, the professional user, the operator…

3.2.5 Organisational aspects Below the organisations conditions of the innovating pilot re listed: •

Creating the organizational conditions of the pilot We needed one project leader who communicates with the LL in Spain, does the administration and assists in the project deliverables. Next to that the transfer needs two developer’s one web and one for the framework. For the Spanish side there is also a project leader with the same responsibilities as the Dutch one. There is one technical lead who knows the ins and outs about the ADL system and who can teach the end users on how to use the ADL system.

•

The collaboration frameworks, maybe partner contracts It is a small ecosystem the only 3th party involved is in Spain for reaching out to the end users. IAV used a home care organization to gather elderly and family members. No contracts where needed for the partners.

•

The efforts on ecosystem development and adaptation Again it’s a very small ecosystem, expansion of the ecosystem will be reviewed when the results of the pilots are evaluated. The first lesson to learn is to what extent the Spanish user (elderly and family) have similar needs for an ADL system. Second task is to build up an ecosystem to reach out to the elderly and figure out if this needs to be done directly or via a care organization?

ICT PSP Project Reporting Template

24

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

4. Technical pilot aspects In this section we described technical adjustments of the system, like: • • • •

SIP server Camera’s Interface Internet connectivity

4.1 Xtramira Case In Deliverable 2.2 it was described that the Xtramira deployment in Finland will be done with Palmia and Helsinki City homecare. The system was supposed to be piloted both in home alarm situation and also by homecare to give virtual care and cure.

After the feasibility study of the Televic system it was apparent that the setup did not meet the technical nor performance requirements of the commercial setting Palmia had in mind. Examples of this are the fact that a secure network for video communication is too expensive and a backhaul solution is needed for in alarm situations, such as analogue telephone line. The pilot was supposed to start in March 2011 but it had to be postponed as a new pilot environment needed to be established.

It was decided jointly with Televic that the pilot will be used in a social context which means that there will be a more common Living Lab approach with the Belgium Living Lab using Xtramira. For this, 10 elderly users living at home and 10 hearing impaired people were recruited for the Xtramira pilot. The 6 month pilot was supposed to start during fall 2011. After Televic had sent the units, they were tested in-­‐house, both by the IT-­‐department of the receiving Living and an external IT-­‐specialist. pilot with Xtramira is estimated to start September 2011 and will be carried out for 6 months. In this new situation Forum Virium as a Living Lab will act as the local ecosystem taking the overall responsibility of the setting up of the pilot: recruitment, installations, training etc. The setup of the pilot is depicted below in Figure 1 Several Xtramira devices are connected to the network. The Xtramira devices can communicate with each other and also with SIP softphone clients installed on a PC or laptop.

The communication is not only an audio connection but also bidirectional video communication is possible. Once a contact is selected in the phonebook or a SIP contact is entered, the other device or softphone client is contacted and a video connection is established.

Different cameras are connected to the Xtramira devices in order to be able to evaluate the video quality and difference between different cameras. There is an infra red camera so that the person living at home can be seen better at night.

Also different cameras with the same technical specifications are used, so that it

ICT PSP Project Reporting Template

25

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 can be tested if there is a difference in subjective quality noticed by the people using the solution.

The SIP server used in the setup is from a third party provider, which connects all the devices to each other. The Configuration server is hosted by Televic Healthcare and provides an online configuration portal to configure the Xtramira devices so that they can be updated remotely by the Living lab. The configuration portal is used for adding contacts to the phonebook of the devices or for uploading an updated software version.

The configuration server collects specific connection data from the Xtramira devices which are up and running. The server knows the IP address of the devices, the last time the device registered. Based upon the feedback of the users more (different) elements can be included in the next software version. These monitoring options at server side are important in case connection problems would arise.

Figure 1: Xtramira pilot setup

4.2 Innoviting Case The ADL system is hosted by Innoviting in the Netherlands under the domain https://adl.livind.nl/. Users in Spain access the service through the URL http://iavante.es/apollon.

Internet connectivity is provided to all the users via SIM cards with 3G data access installed in the ADL router. The service provider is Orange. When available at the user’s home, ethernet connection plus DSL internet access is used too.

ICT PSP Project Reporting Template

26

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 The SMS alert service is provided by Innoviting’s provider in the Netherlands.

The option of using an Andalusian provider that services IAVANTE was explored and technically solved but Innoviting considered it was more convenient to keep the original Dutch provider for the service.

Elderly people who have the system installed at home do not need to perform any kind of active interaction with the system. From their point of view the product is completely passive.

Family members and other informal caregivers that may access the service are trained in the use of the ADL website in a demonstrative session that lasts 30 minutes and have a contact point (apollon@iavante.es) available for any question they may have, as well as for reporting any issue or technical problem they may face when using the website.

The ADL router (a local router that gathers all the information from the motion sensors and other detectors and sends it to the service servers) is configured locally by Iavante following setup instructions provided by Innoviting. The main set up parameters that have to be written for each specific family/router are: • • • •

The system identifier, so that the user access to the website matches the correct device kit installed in the elderly person home.

Internet access parameters for the 3G SIM card installed in the router .

Pairing each installed motion sensor in the home with the corresponding room in the service web interface.

Setting up, in conjunction with the caregivers, the desired parameters for inactivity alerts (motion time-­‐outs) and night/day patterns.

After each system is installed in a user’s home, a test is performed to make sure that all sensors are transmitting correctly their readings to the router and that the router is correctly uploading the information to Innoviting’s servers. Each sensor is tested for detection in the whole room and also for tampering alerts (a small pushbutton in the back of the sensor that allows the system to detect manipulations). The router provides an administration interface that shows all the current reading of the sensors and the list of sensors that are properly paired with the router.

There are two kinds of user frontends, one is the mobile phone and the other is the web interface. The mobile phone gets the SMS messages the server sends out when there is a rule triggered. The other frontend is the web interface where caregivers can login to get a closer look on the current status of their elderly, see also the screenshot below (figure 2). It displays the different insights that the caregivers want to follow. It shows a flow of red to green, where green means it’s going OK and red means something is going wrong.

ICT PSP Project Reporting Template

27

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

Figure 2: Screenshot of ADL interface

4.3 Conclusions It is clear that within the process of cross-­‐border living lab, the pilot set will have to perform some technological adjustments in able to roll out in the various contexts. These adjustments go further than standard localization issues such as translation or other GUI elements. Contextual elements, such as regulations, do also have an impact on technological aspects and conditions: such as liability, security.

Before deploying the technology into the Living Lab, the adjustments and the final set-­‐up need to be tested locally – preferably in a real life setting (reflecting the conditions of the test-­‐users). This does not only enable you to evaluate the adjusted set-­‐up and fine-­‐tune some loose ends, but to detect also non-­‐technical, contextual issues (due to the cross-­‐border difference) that have an impact on the set-­‐up. It is within this pre-­‐testing that the service or product can totally checked and fine-­‐tuned to the level that is fully working and ready for full deployment in the living lab.

ICT PSP Project Reporting Template

28

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

5. Crossborder research goals The common approach for the activities in Work Package 2 is in line and accordance with the guidance and instructions provided by Task 1.2 of Work Package 1 (APOLLON Methodology Framework) and specifically by Deliverable 1.1 (Catalogue of state-­‐of-­‐the-­‐art concepts, existing tools and lessons learned from cross-­‐border living labs networks) and Deliverable 1.2 (Research framework and investigation strategy). Deliverable 1.3 (Framework for Apollon evaluation and impact assessment, including KPI definition and Measurement) will be used for evaluation and KPI assessment. In this sense, the activities encompassed by Work Package 2 fit with several stages of the Living Lab Networks Management Stages, i.e.: Connect, Plan and engage, Support and govern, Manage and track.

The following issues will be taken into account evaluating the cross border •

•

•

•

On the level of the end-­‐users, i.e. how the technology is being used and experienced? This will be done by applying user research in each of the experiments based on a common research framework as populated in section 3.

On the level of the pilot, i.e. how the partners / stakeholders are experiencing the collaboration, whether there are any problems occurring. This will be assessed by means of interactive workshops with these stakeholders or individual interviews.

On the level of the methods and tools used, i.e. whether these are tools sufficient, appropriate, who is using them. During and at the end of the experiment the Living lab will the common approach as well as the Apollon methodology using the impact indicators as determined in WP1; what tools and methods do we need.

On the level of the impact, i.e. to what extent the participating stakeholders benefit from the cross-­‐border aspects, how this is relevant for other Living Labs, whether is can be replicated, what the concrete benefits are in up-­‐scaling. How do we measure the benefits, evaluation of the LL etc. How will we compare things?

In Table 11 below the Cross border research goals and indications how to obtain answers for both cases are listed. These Tables are related to the Table 3 and 5, but Table 11 is specifically focusing on the cross border research aspect.

ICT PSP Project Reporting Template

29

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

Table 11: Cross border research goals Cross border research goal

Achieved via

Responsible party

The contextual difference between the local and remote LL. The way cultural differences can modify the use of the same base technology.

Does the “export” affect the evolution of the system in ways not detected in the originating pilot?

Compare the different settings

Aalto & IBBT

Meetings with the different stakeholders to address specifc needs Listing requirements from the additional partners and contextual factors (such as legislation) In-­‐house testing to assess the transferred technology

Gain knowledge of the healthcare market in other countries; culture, finance, competition. Mainly upfront information; only cultural issues can be gathered from the user questions, because the other points are not essentially user-­‐related.

Next to stakeholders, identifying and gaining insights in the other aspects that are eco-­‐system dependent such as legal framework, technical standers, existing processes…

What is the added research value provided by the operation in a network of living labs from different places with a common living lab methodology?

Compare the topics that are the living labs will be confronted with during cross-­‐border pilots on health e.g. privacy issues, interoperability…

FVH & TLV

Assess them through three monthly reports IBBT, FVH, IAV, AIM

Try to build up better understanding in both the own as well as in other health eco-­‐ systems in order to be more efficient Discuss the role of the Living Lab in the cross-­‐border pilot (facilitator, initiator…)

Analysis of the cross-­‐border collaboration is done by comparing various data with regard to the lessons learned and the Apollon methodology framework (as developed within WP1). To this end we will use the different ‘diaries’ that every partner have used to keep track of its activities and lessons learned. The analysis will be done based on the four levels of the overall Apollon framework: connect, set boundaries & engage, support & govern and manage & track. We will especially focus on the experiences of the SMEs: what are the experiences, impact on the organization, added value…

ICT PSP Project Reporting Template

30

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

Important in Apollon is the benefit Analysis for SMEs. This will be done by looking both at the activities in each of the pilots that are influencing the SMEs and at the assessment of the common approach to cross border network of Living Labs operating in the field of eHealth. The different parts contributing to the improvement for SME’s are measured by different parameters, see Table12 below. Both experiments will capture the data during and after the pilot.

Table 12: Evaluating SMS benefits in cross border pilots SMEs improvements

Measured via

Development of Platform a) Establishment of the platform for SME involvement b) Usage of the platform by SME’s with Living labs in cross c) Amount of Cross-­‐border requests by SME’s border cooperation posted/conducted Increased involvement of a) Types of (new) activities conducted by SME’s in SMEs with Living Labs Living Labs. b) Types of (new) activities conducted by Living Labs to involve SME’s Approach/method, formal interview?

List a number of questions to get feedback from.

Access to new markets a) Effort/funds spent and still needed to enter the beyond the home market foreign market with a real commercial product/service: still a lot of work needs to be done, the first important one is having a local representative, the second is developing a business model covering all local market specifics. b) List of barriers overcome: Better view on the remote Healthcare ecosystem, this is the first step c) List of barriers still to address for access to the market: local representative, development on product to match the remote setting and needs d) Track record (elements) in the new market Access to new ecosystem a) Amount of established (new) contacts of relevant partners and business partners opportunities b) Coverage of established contacts of the different types of stakeholders across the whole value chain: partly, the main stakeholders locally in the remote region are involved

ICT PSP Project Reporting Template

31

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 Expertise in Pan-­‐ European user testing to ensure more user-­‐ oriented services and products and higher user acceptance at European level

a) Amount of user testing experts contacted from remote Living Lab

Support of competitiveness because of enlarged scale and faster deployment of novel services and processes

a) Competition (strength) comparison in foreign market in terms of amount of competitors,

b) Amount of information gathered from other relevant experiments

b) Market share distribution for c4 (4 biggest competitors in terms of market share)

Easy access to all local a) One stop shopping broker/ intermediary relevant stakeholders via available? a single point of access b) Contact established broker/ intermediary Access to tools, applications, services and infrastructure of the different Living Labs as well as the other partners related to the Living Labs

a) Amount of available tools

Lower thresholds to engage in cross-­‐border research, development and innovation

The threshold is lower than before the Apollon project, because a better view on what is needed to go cross border resulted from the project and some practical manuals and “how to’s” are build.

b) Amount of relevant tools actually used

The results of both the pilot projects will be analyzed along these dimensions and parameters as listed in the table. The benefits for the SMEs are important for both the Living Labs involved and the SMEs themselves. In Deliverable 1.3, an extensive set of variables are listed how SME involvement as well as ICT involvement can be measured, the Table 13 for an overview.

Table 13: Proposed measures as suggested in Deliverable 1.3 Measures for SME involvement

Measures for involvement of (ICT)

Number SME engagement activities

Number of products that has been transferred in the experiment

Number of new international partners Number of signed letter of intent between partners and/or customers Number of new businesses generated in ICT PSP Project Reporting Template

Number of cross-­‐border collaboration tools that has been used the experiment Number of NEW (for the stakeholders) ICT-­‐tools

32

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 other countries

that has been used in the experiment

Number of new business proposals

Number of distributed cross-­‐border collaboration activities

Number of new customers in other countries Did the cross-­‐border collaboration lead to increased turnover Did the cross-­‐border collaboration lead to increased customer retention SME engagement activities in detail (e.g. developing technology, user tests, implementation of technology etc) What was the role of the SME in the cross-­‐ border collaboration?

Did the cross-­‐border collaboration tools you used lead to increased access to relevant information Did the cross-­‐border collaboration tools you used lead to increased effectiveness in communication Did the cross-­‐border collaboration tools you used lead to increased co-­‐creation of innovations among stakeholders Which collaboration tools have been used to support the cross-­‐border collaboration in the experiment

One of the important question that needs to be answered within eHealth crossborder pilots is on the “common eco-­‐system”, for example too what extent is it a problem if not the same parties are on board, etc…

The analysis of the benefits of the cross-­‐border network in eHealth Living Labs is going to focus, among others, on the contextual factors; how the pilot specific factors influence the outcomes of the project and how these factors contribute or inhibit the results. Issues such as language, customs and cultural aspects are serious obstacles in cross border experimentation.

Eco-­‐systems can be used as a metaphor for analysis of the context, both before and during the pilot phase an exercise will show the opportunities and challenges for SMEs in the different environments is Europe. The lessons learned from the pilots will be of help in setting up the support structures that the network of eHealth labs needs to provide to be of relevance to its customers.

For the evaluation of the eco-­‐system a standardized model demonstrating the main actors in the ecosystem and the functions that these perform in providing the service is used. This model is filled in for the situation before the start of the project and for the situation during the project. With the different eco-­‐systems described the changes can be visualized and qualified.

Apollon Task 2.4 will address these issues.

ICT PSP Project Reporting Template

33

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

6. Crossborder lessons learned up till now

In this section we describe the first set of lessons learned with regard to the pilot setup and preparations for both cases. In Deliverable 2.4 we will provide extensive overview of the lessons learned when all the pilots and experiments have been conducted.

6.1 The Xtramira case The importance of a local ecosystem with its different stakeholders and their specific roles depends on many different factors. A list of these factors and some explanation on these factors is given below.

•

The local ecosystem provides interesting opportunities for the identification of (local) business opportunities. Without such a local ecosystem and cross-­‐border partners who know these ecosystems and its participants, it would be impossible or it would at least take much more time-­‐ and effort consuming to get to know the eco-­‐system and to be able to identify possible business opportunities.

•

Each eco-­‐system requires a different approach concerning the business models used. Different business models in different eco-­‐systems need to be set up in order to benefit from the roles of the different stakeholders, the different way of working, the established financial streams, etc.

•

Importance of regulations, policies and legal requirements can not be forgotten when bringing a product across borders. Especially in the Health care domain, this factor can not be underestimated. Different financial streams based on specific local/governmental guidelines and regulations are in order. For a business model to succeed, one needs to be aware of these policies and take them into account.

Having good links to the stakeholders of the local eco-­‐system will greatly improve the success rate of doing business, however this can only be accomplished when the importance of efficient communication is acknowledged. Being able to communicate directly, preferable with the correct nuances, and in time with the involved partners is crucial. Part if this efficient communication is strongly linked to the importance of clear contact persons (and their roles and responsibilities). When is aspect is clear, communication can be much more efficient.

•

Being aware of the different terminology that is sometimes used (e.g. the use of resident/patient versus client is a huge difference) in different eco-­‐ systems is important too, since this will only ameliorate the understanding between the different partners.

ICT PSP Project Reporting Template

34

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 •

In setting up business across borders, the importance of third parties and the role of the living lab to act as mediator can not be underestimated and has a great added value.

•

In order to set up a business model across borders, it needs to be identified which are the differences in the case specific settings. For example, e.g. selling products versus services can be related to the differences in eco-­‐systems. Another example in case of the Xtramira™ case is the use of social communication versus alarming a very important issues, social communication is a very important part of wellbeing in one eco-­‐system, but not in the other. Another example is having an alarm centrally dispatched to a central desk or peer to peer communication in a community, which makes a big difference in how the product needs to be launched in a new eco-­‐system. Also the difference in in case specific requirements and functionalities needs to be taken into account, e.g.

•

Secured and encrypted communication needed in the Finnish case versus non-­‐encrypted in the Flemish case.

•

Backhaul solution for alarm needed in case the IP connection fails, then the alarm can still be dispatched over the analogue or mobile phone network.

•

Private configuration portal for the devices in local network is wanted instead of having a centrally located configuration portal.

•

Different resolution is wanted for the camera which part of the product (or even different types of cameras for instance with remotely controlled steering or infrared functionalities for night vision).

•

Support for specific protocols is requested in order to improve the communication security.

These are all examples of different functionalities required in the new eco-­‐ system, which need to be addressed otherwise the product will not be sold.

•

Other aspects are the ethical/social requirements/issues, e.g. social norm: putting cameras in the living space of the people is subject to some anxiety in Flanders, in Finland the healthcare provider decides that the people get camera in their living spaces to improve safety and the people accept this.

Operational issues •

Localization issues (such as different languages in the user interface need to be used): •

Technical issue with the different languages: the lengths of the fields in the user interface are different and can form an issue so that the user interface needs to be redesigned (length of Finnish words is very long compared to Dutch).

ICT PSP Project Reporting Template

35

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 •

Language experts are needed: it would be best of there is one mutual language so that the translation can be done with the needed nuances, otherwise the translation is done from Dutch to English, then from English to Finnish, resulting in loss of specific meaning due to semantics).

•

“How to” procedures: there need to be translated manuals for instance for how to use the product or service, how to install the product, trouble shooting, much frequently asked questions, etc.

•

Extensive product knowledge transfer: much more explicit technical information is needed, and it needs to be written down in order to be able to more easily and efficiently introduce the product in the eco-­‐system.

•

Documentation and training needs to be available in a different language and much more elaborate since informal communication is much less used with partners you do not have relationship with. Examples of documentation and training needed are listed below.

•

Manuals (quick installation guide, quick starting guide, and configuration guidelines)

•

Helpdesk troubleshooting + FAQ

•

Technical (device + configuration)

•

Workshop material

•

Case study

•

Training material

•

Content list

•

Functionalities

•

Set up information

•

Set up of a support desk is needed (decisions need to be made whether a local or not (remote) desk is needed, logging and tracing needs to be available and someone needs to be training to evaluate this data when needed).

•

Need for remote software updates: since the distance is bigger, the devices or services need to be remotely updated when new features or bug fixes are available.

•

Before rollout of the devices at the people’s homes, enough time needs to be sent on setup of the system and the back end, such as network, servers, and configuration portal.

•

When problems occur, there is a need for a local validation environment so that the issues can be reproduced and a technical solution can be found.

•

Clear definition of the different functionalities and applications is needed in order to define a good business model.

ICT PSP Project Reporting Template

36

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 •

Thorough testing is needed of existing functionalities to be sure that the functionality is still working as intended in the new environment.

The new eco-­‐system gives the opportunity to test new functionalities since the stakeholders and the requirements are different. This may result in a broader vision on functionalities and applications and the identification of main mutual functionalities. Knowing these functionalities, the resulting product can be adapted and can be optimized.

•

It needs to be clear to all stakeholders involved in the transfer across border that there is a different focus in the remote living lab than in the local living lab introduced by the difference in ecosystems.

•

However, we also need to be aware of the fact that the focus on applications/services/functionalities which are different than for the “home” market might result in loss of focus for the local market.

Living lab issues •

Distance requires a different approach including communication means and a local representative

•

Importance of (friendly) users with different profiles

•

Huge importance of local representatives

6.2 The Innoviting case The Innoviting case learns us that it is better to involve SME’s in cross border experiments when they: •

Have a real business in their own market, i.e: o revenue stream from existing clients. This will help to define the target group and needed ecosystem. The whole proposition can’t be turned if there a stable income. If a working proposition is not present the SME is able to shift it goals and strategy very easily and in big project this will not be recommended. Also this will make the start-­‐up phase of the project slow. There is no clear goal of scope and the end result will be able to drift into other directions. o commercial products. Same as description above. A finalised product sets boundaries on the projects and prevents drifting. Also when there is an amount of clients using the solution this means the project is tested. Innoviting transferred the new (and still in development) solution to Spain. Keep in mind to use the same product as used in the local country and not transfer to the next generation. This means also that you have to get rid of hiccups at the start, and there will be enough already so you don’t want these extra ones. o On the plus side, the flexibility can come in handy when modifications are needed to be done to make the solution work in

ICT PSP Project Reporting Template

37

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

•

other countries. And lessons learned that this is a 100% chance this is going to occur.

Have sufficient capacity (manpower) that can be used for cross boarder experimentation, as current business always prevails above (subsidized) research projects, e.g. a large business deal in home country is always more interesting than small pilots abroad. Capital-­‐intensive projects have a much lower heart-­‐beat than SME product development. o For an SME in the start-­‐up phase the liquidity of the business is a main concern. This can put the focus on sales and income instead of the long term R&D.

Involvement of SME’s should be as late as possible in crossborder projects, not long before the actual start of the research project as currently is needed in the EU projects, SME’s need flexibility and planning needs to be anticipating on ongoing product development during project as SME’s have •

No desire to work on last-­‐years technology

•

New insights in needs from cross-­‐border cooperation

•

The whole research setup is not interesting for an SME. It’s interesting to have a look on the side and take some parts that are applicable for the SME. But an SME just wants to work, move forward and see results, research frameworks are more seen as a delay.

•

There could be a risk if you involve SME’s later on in the project that you can’t find one? But don’t forget that SME’s can decided much faster than multinationals, can shift their goals more easily and could use some money for R&D. You can only pull off this risk if you have a large network of SME’s and you know a few who would fit in the project and are willing to do the work. If you have to find SME’s you’re going to lose a lot of time because they are hard to find because of the lack of external communication.

6.3 General conclusions Both cases provided lessons learned with regard to the pilot setup and preparations. All aspects can be integrated in to a SWOT analysis to speed up the setup and preparations when wanting to conduct a cross border pilot. In Deliverable 2.4 we will provide more cross-­‐border lessons learned, also from the execution of the pilots. To sum up, important aspects are:

Importance of local ecosystem with its stakeholders and their roles •

Need for solid eco-­‐system covering all roles and activities

•

Early identification of (local) business opportunities.

•

Early investigation of local regulations, policies and legal requirements

•

Setting-­‐up partner meetings at the early stage so that scope can still be adjusted

ICT PSP Project Reporting Template

38

Version: Final, 06/02/2012

Apollon – Deliverable 2.3 •

Need for a central actor in the remote context (Living Lab or business unit) that act as coordinator

•

Importance of (friendly) users with different profiles

•

Define the win-­‐win for all parties and use this as the framework for the pilot set-­‐up

•

Involve SME’s in cross border experiments that have existing revenue stream from existing product in their own market real business in their own market, i.e:

Operational issues •

Perform an SWOT analysis

•

Iterative, quick adjustment of technologies

•

Follow-­‐up by all partners –get them involved

•

Keep partners in the loop

•

Use tracking methods so every partners knows what the other is doing and their status (as close to real-­‐time)

•

Local technical validation as soon as possible, i.e. take into account the differences in language (documentation, interface, etc.)

•

Set-­‐up support helpdesk

•

Think of the language

ICT PSP Project Reporting Template

39

Version: Final, 06/02/2012

Apollon – Deliverable 2.3

References

Apollon Deliverable 1.1: “A Catalogue of state-­‐of-­‐the-­‐art concepts, existing tools and lessons learned for cross border Living Lab networks” Apollon Deliverable 1.2: “Research Framework and investigation strategy” Apollon Deliverable 1.3: “Framework for APOLLON Evaluation and Impact Assessment including KPI definition and measurement” Apollon Deliverable 2.1: “Requirements” Apollon Deliverable 2.2: “Common Living Lab Approach”

ICT PSP Project Reporting Template

40

Version: Final, 06/02/2012