Apollon - Homecare and Independent Living - Evaluation and Recommendation

DELIVERABLE Project Acronym:

APOLLON

Grant Agreement number:

250516

Project Title:

Advanced Pilots of Living Labs Operating in Networks

Deliverable 2.4 Evaluation and recommendations report on the cross border experiment Revision:

Final

Authors: Hendrik Hielkema (Aalto University) Bram Lievens (IBBT) Bidatzi Marin (Iavante) Tim van den Dool (Innoviting) Gohar Sargsyan (Logica) Petra Turkama (Aalto University) Marianne Dannbom (Forum Virium Helsinki) Daan Velthausz (AIM) Chris Bannink (Logica), Karen Willems (IBBT)

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.4

Revision History Revision Date 0.1 0.2

Author

14/02/2011 Hendrik Hielkema 24/10/11

0,3

15/03/12

0.4

26/03/12

v1

30/03/12

Hendrik Hielkema Hendrik Hielkema Hendrik Hielkema Bram Lievens

Organisation Description Aalto University

initial document layout and division of work

Aalto University

added text on Ecosystems analysis from B.L.

Aalto University

collected contributions partners

Aalto University IBBT

collected contributions partners Preparation for submission to PMT

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 Apollon

2

Final Version

Apollon – Deliverable 2.4

Management Summary One of the main objectives of the Apollon Project was to perform a set of cross border pilots in Europe for SME’s and Large Enterprises. This Deliverable 2.4 describes the cross-border activities of WP2 within the domain of Homecare and Independent Living, their respective results as well as list of recommendations and lessons learnt. The cross border activities were focussed on the transfer of existing technologies from one context to another. During this transfer we looked specifically to what extent a common eco-system, present in each of the locations, would foster the cross-border pilots.

In order to do so, we organised our activities on the following three specific cross-border experiments:.

•

•

•

Belgium – Finland: Within this pilot the Belgium SME Televic, which has developed a Homecare supporting communication technology – deployed in their home market, transferred their system, called Xtramira® to the Finnish market. The service provides a video and audio communication between client and the homecare providing organization. This was taken up by the Finnish Living Lab, which had identified local actors that were in need of such service. A lot of effort was put into the preparations and contextualisation of the service.

Netherlands – Spain: In this experiment the ADL system is an intelligent home automation application for the elderly of the Dutch SME Innoviting was transferred to Spain. The system that uses small wireless sensors capable of recognizing the behaviour of residents’ daily activities, was successfully transferred and tested within different Spanish households.

Here also the local Living Lab, IAV, played a crucial role in the set-up and deployment of the technology..

Netherlands – Belgium: Next to the predefined experiments, an additional experiment was executed, as a result of the network activities of the project. This experiment transferred the I Can Help service, a social emergency service, developed by Logica Netherlands, a large enterprise, to the Belgium market. Again it was mainly the local Living Lab, IBBT, which facilitated this process by searching for the appropriate partners and establishing of the eco-system. As this experiment was conducted at the end of the APOLLON project we were able to integrate and by so evaluate the defined APOLLON approach as well as the different tools and methods used in the previous experiments.

Based on these pilots we were able to: •

•

Define and compare the different Homecare and Independent Living Lab approaches.

Develop a transfer strategy and working methods

ICT PSP Apollon

3

Final Version

Apollon – Deliverable 2.4 • • •

Validate the used methods and tools for cross-border pilots in the Homecare and Independent Living network Map the different contextual factors, including the regulatory and legal issues as well as the service/product value-chain and eco-systems Evaluate to what extent the network can be used for exploring new and emerging markets within the Homecare and Independent Living.

The lessons learned with regard to cross-border pilots and networks in the domain of the Homecare and Independent Living are described in this deliverable. They are situated on various levels: •

•

•

Tools and methods: filling in the overall APOLLON approach and contributing with some specific methods – such as the requirement analysis...

Collaboration and eco-system: identifying key-roles and activities within the eco-system as well as the challenges for the Living Lab as key-actor in the process Domain-specific issues: Listing different domain specific elements that are important within cross-border pilots in the domain of Homecare and Independent Living such as privacy, liability, ethics, requirementschecklists, safety, maturity, reliability (testing!), costs, trust, rules & regulations and access to end-users.

The lessons learned, as described in this deliverable are not only beneficial to future cross border research activities for Living Labs communities but also for research organisations and the commercial activities for SME’s and large enterprises. They also provided insights for the cross-border domain network.

ICT PSP Apollon

4

Final Version

Apollon – Deliverable 2.4

Table of Contents Management Summary ..................................................................................................... 3 1.

2.

3.

4.

5.

6.

Introduction .............................................................................................................. 10

1.1 1.2 1.3

Objectives of deliverable ..............................................................................................10 Background .......................................................................................................................10 D2.4 in Relation to the Tasks and Deliverables ....................................................10

Pilots of wp2: the Belgian-Finnish Experiment............................................. 11

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

Description of the Experiment ...................................................................................12 Timeline of the Experiment, the Connect Phase ..................................................12 Timeline of the Experiment, the Plan and Engage Phase ..................................16 Timeline of the Experiment, the XtramiraÂŽ v2 Plan and Engage Phase .....25 Timeline of the Experiment, Tunstall; Connect Phase .......................................26 Timeline of the Experiment, The plan and engage phase .................................30 Timeline of the Experiment, the Support and Govern Phase ..........................31 Timeline of the Experiment, Manage and Track Phase .....................................31 Outcomes on the pilot level .........................................................................................34 Lessons learned on the pilot level ..........................................................................34

Pilots of wp2: Dutch-Spanish experiment....................................................... 36

3.1 3.2 3.3 3.4 3.5 3.6 3.7

Description of the Experiment ...................................................................................36 Timeline of the Experiment, the Connect Phase ..................................................37 Timeline of the Experiment, the Plan and Engage Phase ..................................39 Timeline of the Experiment, the Support and Govern Phase ..........................44 Timeline of the Experiment, the Manage and Track phase ..............................49 Lessons learned on the pilot level .............................................................................60 Tools and Methods deployed in the pilots..............................................................65

Pilots of wp2: the Dutch-Belgian Pilot .............................................................. 67

4.1 Description of the experiment ....................................................................................67 4.1.2 About the technology ........................................................................................................... 67 4.1.3 Objectives of the pilot .......................................................................................................... 68 4.1.4 Set-up .......................................................................................................................................... 69 4.2 Timeline of the Activities, the Connect Phase .......................................................76 4.3 Timeline of the Activities, the Plan and Engage phase.......................................79 4.3.2 The local ecosystem .............................................................................................................. 80 4.3.3 Contextualisation of the technology .............................................................................. 82 4.4 Timeline of the activities, the Support and Govern Phase................................86 4.4.2 Research set-up ...................................................................................................................... 87 4.4.3 Implementation of the technical infrastructure and deployment of the experiment............................................................................................................................................... 89 4.4.4 Management of the different stakeholders involved .............................................. 90 4.5 Manage and track: the outcomes of the experiment ..........................................92 4.5.2 Outcomes on the pilot level ............................................................................................... 93 4.5.3 Lessons learned on the pilot level .................................................................................. 98

Tools and Methods deployed in the pilots ....................................................102

5.1

Translation tool ............................................................................................................ 102

Ecosystem for Health and wellbeing pilots ..................................................104

6.1 6.2

Scope and objective ..................................................................................................... 104 Setting the context & situating the Living Lab concept ................................... 104

ICT PSP Apollon

5

Final Version

Apollon – Deliverable 2.4 6.3 The ecosystem concept............................................................................................... 106 6.4 Ecosystem thinking ...................................................................................................... 107 6.5 Health (care) ecosystems and health (care) systems ...................................... 110 6.6 The health care system and long-term care system: an overview .............. 110 6.7 Actors and roles in a living lab ecosystem active in homecare & independent living .................................................................................................................. 113 6.8 Towards a ecosystem for Living labs dealing on Independent Living and Health .......................................................................................................................................... 115 6.9 Roles in a living lab active in homecare & independent living .................... 118

7.

Recommendations for Cross Border Living Lab collaboration .............121

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11

Privacy .............................................................................................................................. 121 Liability ............................................................................................................................ 122 Ethics ................................................................................................................................. 122 Checklist of requirements ......................................................................................... 123 Safety ................................................................................................................................. 124 Maturity ........................................................................................................................... 124 Reliability ........................................................................................................................ 124 Costs .................................................................................................................................. 125 Trust .................................................................................................................................. 125 Rules and regulations ............................................................................................... 126 Access to end-users ................................................................................................... 126

8.

Conclusions ..............................................................................................................129

9.

References ................................................................................................................132

10.

ANNEXES .................................................................................................................133

Annex 1 professional health care providers in Belgium ........................................... 133 Annex 2 health insurers in Belgium ................................................................................. 138 Annex 3 The health care system in Finland ................................................................. 138 Annex 4 The healthcare system in Spain-Andalusia ................................................... 141 Annex 5 Short overview of Dutch healthcare ............................................................... 143

ICT PSP Apollon

6

Final Version

Apollon – Deliverable 2.4

List of Figures Figure 1 Relationship between tasks and deliverables of WP2 ................................... 11

Figure 2 The connect phase activities ..................................................................................... 13

Figure 3 The Plan and Engage Phase ....................................................................................... 16 Figure 4 the Local Network Partners ..................................................................................... 17

Figure 5 the Plan and Engage phase ........................................................................................ 26

Figure 6 the Connect Phase ......................................................................................................... 27 Figure 7 Tunstall System Environment .................................................................................. 28 Figure 8 the Videra Technical Environment. ....................................................................... 28 Figure 9 the Plan and Engage Phase ........................................................................................ 30 Figure 10 the Support and Govern Phase .............................................................................. 31 Figure 11 the Manage and Track Phase.................................................................................. 31 Figure 12 the Connect Phase ....................................................................................................... 37 Figure 13 Ecosystem Spanish Experiment............................................................................ 39 Figure 14 the Plan and Engage Phase ..................................................................................... 40

Figure 15 Location of sensors in test setup .......................................................................... 41 Figure 16 the Support and Govern Phase .............................................................................. 44

Figure 17 Locations of the Users ............................................................................................... 48 Figure 18 Location of Sensors in the House ......................................................................... 49 Figure 19 Manage and Track phase ......................................................................................... 50 Figure 20 Totals for the 15 users are 261 SMS messages and 252 e-mail messages. ............................................................................................................................................. 53 Figure 21 The 'Apollon I Can Help' service being transferred to Belgium (photo taken from the kick-off session) ................................................................................................ 67 Figure 22 screenshots of the application ............................................................................... 70 Figure 23 The connect phase ...................................................................................................... 71 Figure 24 The plan and engage phase ..................................................................................... 72 Figure 25 the support and govern phase ............................................................................... 75 Figure 26 Volunteers on March 23, 2012 at 16:39 Dutch pilot.................................... 76 Figure 27 the connect phase ....................................................................................................... 77

Figure 28 the plan and engage phase ...................................................................................... 80 Figure 29. Screenshot of SMS message dashboard............................................................ 84

Figure 30. Screenshot of received messages ........................................................................ 84 ICT PSP Apollon

7

Final Version

Apollon – Deliverable 2.4 Figure 31 the Support and Govern phase .............................................................................. 86 Figure 32 screenshot of questionnaire ................................................................................... 88 Figure 33. Kick-off of the 'I Can Help' pilot in Flanders with the testpanel ............ 90

Figure 34 the manage and track phase ................................................................................... 93

Figure 35. Overview mobile phone skills test panel ......................................................... 94 Figure 36 Attitude towards integrating SMS in the MMC service workflow .......... 95 Figure 37 user experience results iPhone users (voluntary drivers) ....................... 96

Figure 38 user experience results mobile phone users (voluntary drivers) ......... 97

Figure 39. Comparison of two different devices for I Can Help ................................... 99 Figure 40 examples of technology ......................................................................................... 100

Figure 41 Volunteers on March 23, 2012 at 16:39 Dutch pilot................................. 100 Figure 42 User interface in Dutch .......................................................................................... 102 Figure 43 The user interface with texts translated and corrected in Finnish .... 103 Figure 44 From ecosystem thinking to the definition of a Living Lab ecosystem in homecare & independent living.............................................................................................. 106 Figure 45 Characteristics of the business ecosystem (Peltoniemi, 2005)............ 107 Figure 46 Overview chart of the Belgium Health System ............................................ 111 Figure 47 Position of a Living Lab in Homecare and Independent Living ........... 112

Figure 48 generic actors in a living lab active in homecare & independent living ............................................................................................................................................................... 116

Figure 49 the informal caregivers in the homecare and independent living domain ............................................................................................................................................... 117 Figure 50 the professional health care providers in the homecare and independent living domain ....................................................................................................... 118 Figure 51 the Belgian Health Insurers ................................................................................. 138

ICT PSP Apollon

8

Final Version

Apollon – Deliverable 2.4

List of Tables Table 1 First Wave Users ................................................................................................................ 47 Table 2 Second Wave Users .......................................................................................................... 47 Table 3 Third Wave Users............................................................................................................... 48 Table 4 Overview of End Users .................................................................................................. 51 Table 5 actors and roles ................................................................................................................ 71 Table 6. Ecosystem in Netherlands: actors and roles...................................................... 73 Table 7 modifications to the system ........................................................................................ 73 Table 8 research setup ................................................................................................................... 74 Table 9. Actors and roles............................................................................................................... 78 Table 10. Ecosystem in Flanders: actors and roles ........................................................... 81 Table 11. Present situation MMC service in Flanders ...................................................... 82 Table 12 needs and expectations .............................................................................................. 82 Table 13. Research in the Experiment .................................................................................... 86 Table 14 various issues with the system that were solved during the pilot .......... 92

Table 15 The Evolutionary Stages of a Business Ecosystem (James F. Moore, 1993) ............................................................................................................................................................... 109

Table 16 Ecosystem specific characteristics ..................................................................... 113 Table 17 generic actors in the living lab ecosystem active in homecare and independent living ........................................................................................................................ 115 Table 18 Roles and Actors ......................................................................................................... 120

ICT PSP Apollon

9

Final Version

Apollon – Deliverable 2.4

1. Introduction 1.1 Objectives of deliverable Deliverable 2.4 will describe the cross-border activities as well as the different results. This report will also deliver a set of requirements and recommendations for cross-border network of Living labs.

This report outlines the considerable changes that have taken place in the pilots that have been executed during the Apollon Project. For the changes an explanation and justification is provided.

In this deliverable a timeline of events is included to demonstrate the contribution to the cross border collaboration of the various partners.

1.2 Background

Within the Homecare and Independent Living pilot, the objectives are to investigate the different contextual factors that impact Homecare and Independent Living RDI. Also the specific Homecare and Independent Living market structures are investigated as well as interoperability protocols for transferring Homecare and Independent Living experiments between different Living labs. We have addressed these objectives by means of conducting several local experiments in cross border context (Living Lab setting). These comprehend the preparatory work for the different Living Labs and local experiments, the set-up and deployment into the other Living Labs, and the evaluation of the tools and methods used.

Based on this pilot we have:

1. Defined and compared the different Homecare and Independent Living Lab approaches.

2. Developed a transfer strategy and working methods 3. Validated the used methods and tools for cross-border pilots in the Homecare and Independent Living network 4. Mapped the different contextual factors, including the regulatory and legal issues as well as the service/product value-chain and eco-systems 5. Evaluated to what extent the network can be used for exploring new and emerging markets within the Homecare and Independent Living.

1.3 D2.4 in Relation to the Tasks and Deliverables

ICT PSP Apollon

10

Final Version

Apollon – Deliverable 2.4

Figure 1 Relationship between tasks and deliverables of WP2

This deliverable is based on the Task 2.4 that evaluates the experiments done in Grenada, Helsinki and Brussels. Input from the Tasks 2.1 to 2.3 and the deliverables 2.1 to 2.3 is used in this deliverable. Figure 1.1 shows the relationship between the various tasks and Deliverables in Work Package 2.

In Task 2.4 and Deliverable 2.4, Evaluation and Recommendations the main focus is on describing the pilots that have taken place and the lessons learned from them. The Pilots are described using Time Lines that describe the different steps taken, the choices made and the reasons to change the intended pilots at various points. The recommendations come from the lessons learned and, together with the general methodology for Living Labs operating in Cross Border Experiments made by Work Package 1, form the recommendations to future projects in the Homecare and Independent Living domain.

Next to this the work package will be in a permanent interaction with supporting partners, relevant stakeholders and governmental organizations in order to exchange the knowledge gathered and to explore the possibilities for creating a sustainable network of Homecare and Independent Living Labs.

2. Pilots of wp2: the Belgian-Finnish Experiment

ICT PSP Apollon

11

Final Version

Apollon – Deliverable 2.4 The following chapter chronologically describes the activities that have taken place within the originally Belgian-Finnish experiment in WP2 devoted to transferring the Televic Independent Living system marketed under the name of Xtramira® to Finland for piloting with relevant users by the Forum Virium Living Lab in Helsinki. This chapter also discusses the subsequent project with the Tunstall technology that was used in the actual realized experiment.

2.1 Description of the Experiment

The Belgium SME Televic has developed a Homecare supporting communication technology that is at present on the market in Belgium. This system, called Xtramira® is in use at the OCMW Kortrijk with approximately 30 clients.

Xtramira® provides a video and audio communication between the independent living client and the homecare providing organization. It also allows relatives and friends to communicate with the Client via a software application installed on a pc or mac and an internet connection.

The Brussels based Living Lab IBBT has collaborated with Televic in the Telesenior project. This project has investigated the usage and possible benefits of the Xtramira® in Homecare and alarm situations as well as the possible benefits for using the Xtramira® system for social interaction.

On the basis of the experience with the Xtramira® technology in Kortrijk and the learning from the Telesenior project the SME Televic joined the Apollon Project to transfer the technology to a foreign country to learn about:  How a technology such as the Xtramira® can be transferred to a foreign context  What the best process is to initiate and execute such a transfer  The technological performance of the Xtramira® system in a foreign context

The IBBT Living Lab supported this initiative. Also the Helsinki based Forum Virium Helsinki Living Lab joined this experiment and agreed to facilitate the transfer of the technology to the Finnish Homecare and wellbeing ecosystem that Forum Virium Helsinki has access to.

2.2 Timeline of the Experiment, the Connect Phase The connect phase in the project started with the completion of the DOW. During the Connect phase the first outline of the project, as it was to be conducted in Finland, was made and plans for implementation were drawn up.

ICT PSP Apollon

12

Final Version

Apollon – Deliverable 2.4 Connect:

Support and Govern:

Plan and Engage:

Manage and Track:

• Initial planning and coordinating activities • Identification of requierments • Analysis of Ecosystem • Search and approach of potential partners Figure 2 The connect phase activities

The starting point was a meeting between the SME Televic and the Living Lab Forum Virium Helsinki in conjunction with the kick-off meeting where the local competition, segments and customer needs were discussed and the market potential/segment for Televic product and the technical features of the product were covered. After that, based on the experience of Forum Virium Helsinki in eHealth, a list of potential partners in the local ecosystem was drawn and contact was made to the most lucrative one: Helsinki City Home Care and Palmia.

At the kick off meeting during M1 the partners discussed the project and took steps in the following areas:  coordination

In Belgium most actions were the result of the Telesenior project, to transfer the project setup to the foreign context the most benefit of comparing the situations can be gotten. As a preparation of the pilot, the sending Living Lab (IBBT) performed a full analysis of this Telesenior project in which it describes the ecosystem, the set-up, the issues… Additional research on the use and experience with regard to the XtramiraTM device was performed. This document (available as a separate document) was then used by the receiving Living Lab as a guideline and supportive tool. Also for the research partner Aalto, this document provided a series of questionnaires that enabled them to perform similar research as in Belgium, allowing cross-country comparable results. To transfer such a project there was little need to find new parties in Brussels/Kortrijk but more so in Finland. The Finnish Living Lab will coordinate the activities in the pilot in Helsinki.

The receiving Living Lab in the foreign country together with the sending Living Lab from the originating country can act as central players in getting different stakeholders from different countries together, possibly resulting in the identification of common business interests and finally in partnerships. The

ICT PSP Apollon

13

Final Version

Apollon – Deliverable 2.4 Living labs could function as a mediator here between different companies in order to establish relationships more efficiently.

It was decided that Televic Healthcare was available remotely by means of Skype, email, fixed line telephone and cell phone for answering any questions that would arise. It was also made clear that someone would provide support as soon as possible when questions arose. The device is manufactured in such a way that setting up the actual device and connecting it to the network and television is straight forward. This way the amount of support needed for this aspect is limited. The main questions were related to configuration issues and how to exactly configure the technical parameters of the device, such as network connection and SIP connection. Since we noticed this in the test lab, it was decided that Televic Healthcare would preconfigure the other devices before shipping them to Finland, in order to lose less time for roll out of the devices.  initial planning,

The first discussions led to an initial analysis of the ecosystem that showed the need for local partners in Helsinki with the access to both the customers and the infrastructure, technical and alarm desk functionality. The Living Lab contacted these partners and started with the setup of the local network for the experiment.  technical specs

To support the Living Lab in the partner search the SME Televic has provided FVH with a set of brochures and a datasheet on the Xtramira® product to promote the system in Helsinki.

One of the issues that came up at first was that the product datasheet and Xtramira™ brochure did not describe in detail all the technical details needed for rollout and installation. Also the list of specific functionalities supported by the Xtramira™ was missing, and should be described more formally in order to inform the other partners better. This would also provide the remote Living Lab with more means to be prepared on the actual rollout and also this would avoid possible misunderstandings or wrong expectations.

Since Finland does not belong to the home market of Televic Healthcare and is thus not part of their commercial focus, the roadmap of product development within the company cannot be fundamentally changed according to (local) technical requirements or wishes without a significant and concrete commercial deal behind it. It is important to focus on the requirements which are important for the local/home market and on requirements which are common for different markets.  competitive situation

Living Labs form an easy gateway between companies and local user groups.

Different barriers, such as language and cultural differences, are difficult to cross without a local actor such as a Living Lab. ICT PSP Apollon

14

Final Version

Apollon – Deliverable 2.4 The Competitive situation in Finland combined with the information from the product brochures led to a serious interest from the potential partners Palmia and Helsinki City Home Care, a department in Helsinki Health Care Services..  application area of interest by SME

Televic is an SME that does not have the financial ability to do many projects and therefore must select the projects that they do careful. The choice to take the opportunity that APOLLON offered was because it gave the best chances to learn about cross border collaborative experiments as well as the process to technology transfer.  ethical issues,

Directly at the start of the project various differences in the approach to the service came to light. It is important to be mindful of local differences and customs, awareness of this difference in used terminology helps in communicating with each other. It also sometimes can provide insight into the way of thinking. For instance, in Belgium we use the terms “patients” and “residents”, in Finland however the terminology is “client”. This implies a completely different way of thinking that is also reflected in the business model.

The understanding gained from the initial discussions in the first period and expectations of the project are partly summarized in a SWOT analysis from the point of view of the SME:  Strengths

o Outside the very local way healthcare works including different stakeholders o Different applications that are interesting o Localization + how to

 Weaknesses

o Distance requires a different approach including a local representative

 Opportunities

o See different eco systems and policies, and by consequence requirements o Identify different business opportunities

 Threats

o Focus on applications/services/functionalities which are different than for our “home market”, loss of focus

ICT PSP Apollon

15

Final Version

Apollon – Deliverable 2.4 In M4 The Finnish Living Lab Forum Virium Helsinki has received the documentation from Televic and approached Palmia and Helsinki City Home Care with this material to promote the initial project idea. Forum Virium Helsinki suggested that Palmia will be the organization that is going to run the main technical service provision in the pilot and that Helsinki City Home Care would provide access to the customers and the nursing staff.

Helsinki City Home Care and Palmia are both linked to the municipality of Helsinki, where Helsinki City Home Care is a department that provides healthcare and related services mainly for the elderly, Palmia is an independent company, but fully owned by the municipality of Helsinki.

At the meeting in Valencia, April 2010, M6 the decision to continue discussions with Helsinki City Home Care and Palmia was supported by Televic and the other partners in the WP2. It was agreed to continue with the plan and a local “project group” was established. The project group started its work be defining rules and responsibilities of Palmia, Aalto, & FVH, and started the project planning.

2.3 Timeline of the Experiment, the Plan and Engage Phase The second phase of the experiment: where the localization activities, the research setup and the user selection are done. The local circumstances and the progressing technology made for changes in the setup of the experiment. The methods for gathering the research data were chosen and a test setup at the controlled environment at the premises of Palmia and a test setup at Aalto University CKIR was made.

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

• agreements with partners in local network • Technology testing/local setup • Localization of technology • research design • permissions • user selection Figure 3 The Plan and Engage Phase

After an understanding with Palmia there remained the issue regarding the costs for operationalizing the local pilot. This concentrated on the costs of the ICT PSP Apollon

16

Final Version

Apollon – Deliverable 2.4 connections to the clients, although this question was not answered conclusively during the period M5 to M12. The partners in the local network in Helsinki decided to continue with the project.  Local network partners in Helsinki

Figure 4 the Local Network Partners

In this figure all the active participants for the Helsinki Local Experiment are shown:

Palmia was responsible for the technical running of the pilot infrastructure and the alarm function, helpdesk etc. Terveyskeskus would provide the homecare for the clients participating in the system, (in the figure the clients are in the centre) Forum Virium Helsinki would provide the general management of the operations and Aalto University would collect the research data and provide analysis.  Technology Testing

Televic has provided the Finnish partners with a set of Dutch language documents describing the system and the general operational principles of the technology and two complete sets of the Xtramira® system. The documents, being a “fast installation guide” and a graphical representation of the systems technical requirements, were translated by Aalto and made available.

One of the two sets was delivered to Aalto and one set was delivered to Palmia with intention to understand the functionality of the technology and the ability of the system with regards to speed, sound and image quality, reliability and durability. At both places a setup was build that allowed for demonstration of the ability of the system and experimentation.

The results:

o

ICT PSP Apollon

The technology testing showed that the quality of the camera and the image resolution was insufficient for one of the critical functions, namely to see that customers who do only take medication under supervision 17

Final Version

Apollon – Deliverable 2.4

o o o

o

o

actually do so. At present that can only be ensured by a Home Care Nurse visiting the client.

There is no possibility to connect more than one single camera at present.

It is not possible to remote control the camera, with for example move, zoom or other functions.

The Xtramira® a does not support GSM or other mobile broadband or WiFi or alternative mobile communication technology. According to the law in Finland there needs to be a back-up system for the alarm in case of e.g. power failure.

The communication between the Xtramira® box and the SIP server, as well as the communication between Xtramira® devices and each other or an alarm desk is NOT encoded, shielded or protected in any meaningful way. This is not acceptable in Finland, Medical relevant data, such as can be expected to be transferred via the Xtramira® system needs some form of protection.

The Xtramira® does not have a software built in module for VPN, (virtual Private Network)

All these questions were discussed at the end of the testing period in M9-M12.  Localization of the technology

To work in a Finnish setting the language on the systems had to be changed. At the start of the Apollon project the language on the Xtramira® was either Dutch or French, the languages of the home country. The same was true for the configuration portal that is used to remotely configure the devices once they are installed at the customers location.

Porting product or service across borders, usually means that the user interface needs to be provided a different language. In case of the Xtramira™ pilot, the user interface on the television for the end-user at home needs to be in the native language, Finnish. The more organizational related interface for configuring the device can be provided in English. For this the user interface on the television needed to be translated to Finnish. Previously the configuration portal for configuring the devices online was only provided in Dutch. The portal was translated to English so that the Finnish partner would understand the portal and could evaluate the portal.

The challenges that were met when translating the end-user interface to Finnish were threefold. Firstly, for optimizing the semantic meaning of the user interface, it would be good if someone with knowledge from both Dutch and English could do the translation. Since now, the interface was translated to English first; losing some nuances and then the interface is again translated from English to Finnish, with again changes of loss of semantics. So having language experts with knowledge from mutual (native) languages would enhance the quality of the translation significantly. Secondly, not only the semantic meaning of the words is important, also the context in which the words are used is important when translating.

ICT PSP Apollon

18

Final Version

Apollon – Deliverable 2.4 The first time we did the translation, only the different lines of text were transferred to the Finnish partner, who translated these lines of text as good as possible. But when we implemented these translations into the actual user interface on the television and the Finnish partner saw this interface at work, it became apparent that some of the translation did not fit into the actual used context. So next time, we did not only use the text itself, but we also took screenshots of the user interface in which the text is used, so that the actual context could be taken into account when doing the translation. And last but not least, we encountered two technical issues with the translation as well.

The Finnish language typically contains much longer words than the Dutch language, which gave problems in the visual representation of the text in the user interface. The user interface needed to be redesigned sometimes in order to be able to fit the words on the screen. Another technical issue we encountered was the fact that we reuse some specific words in different lines of text and thus in a different context. However in the Finnish language these words sometimes needed to be translated different according to the context in which they were used. But since in the program code there was only one parameter foreseen for this word (with thus sometimes two translations depending on the context), we needed to adapt the programming code in order to be able to support this.

As described above the translations were done in several phases, each time ameliorating the result. The translations of the user interface on the television from Dutch to English and from English to Finnish took place in June-July 2010

by Televic Healthcare and Aalto. The translation of the configuration portal was done by Televic Healthcare in July-August 2010. The translation of all documentation and training material was done October-November 2010.

The task to translate the device interface was taken by Aalto and several actions were taken. At first, (before Aalto had the availability of the device) a list with terms and texts from the interface was sent to Aalto, translated by Aalto from Dutch to Finnish, and returned. This proved to be not a very good method, because the syntax of the Finnish language is different. Several attempts to explain the meaning and the context were made from both sides, until Screenshots were used, demonstrating the actual context of the text. This worked well and is now a Apollon tested method for user interface translation, see D1.4. After completion of the translation Televic added the Finnish Language package as an option on their configuration portal.

The configuration portal was translated into English by Televic.

After setting up the test labs in Televic Healthcare and Aalto, some features were reported that would increase the stability and applicability of the product. All involved partners described in emails which parameters should be monitored, logged and traced. Televic Healthcare implemented these parameters and therefore released a new software version. Also when testing the devices in its new setup, some shortcomings that became obvious in a new setting were reported by all partners which were fixed in a new software release. Each time a new release was made, this release is made available on the configuration portal for download of the devices and the partners involved were notified by means of email.

ICT PSP Apollon

19

Final Version

Apollon – Deliverable 2.4 The reported bug fixes that were essential to the working of the device were always fixed as soon as possible. The new release including the translation of the user interface on the television and the release of the English configuration portal were not planned on the roadmap, but were executed because there are essential for the cross-border pilot. The extended monitoring, logging and tracing options were originally part of the roadmap, however due to the crossborder pilot, implementing these functionalities was shifted to an earlier date so that they could be useful in the pilot.  Research Design,

To collect the relevant data that is needed to make the results of the experiment comparable with the original project that was done in Belgium, called Telesenior, the documents from the Telesenior experiment were sent (under condition of Non Discloser) to Aalto in M9. Based on the user profiling and the questionnaire used in the Telesenior project a research design was made that included interviews and focus group discussions, as well as an online questionnaire for the different user groups in the experiment. The identified user groups were the; o o o o

Clients, those people who are receiving the system in their daily life Care providing staff, the nurses who are giving the care to the clients Alarm desk staff Management of the various partners

For these groups, especially the clients and the care providing staff, a schedule for interviews was made and interview guides were done.  Permissions

In Finland there is a strict control on experimentation within a healthcare of wellbeing setting. As soon as there is any activity that requires the participation or involvement of care receiving clients there must be an ethical permission from the participating healthcare organization.

This permission, the so-called Tutka permission, has to be applied for by the party that does the actual research. In this experiment that was Aalto and Aalto did file an application for permission for the research with the Xtramira® system. This application was filled in M10 and after several rounds of adjustments granted to Aalto in M14.  User selection

The user selection was done by the Homecare providing partner Terveyskeskus.

They selected 2 separate groups of users, o o

Users who are elderly, possibly in earlier states of dementia.

Users who are younger but who have a substance abuse induced mental degradation to the level where they are completely care dependent.

These two user profiles were used by Helsinki City Home Care to select 10 users of each group, 20 users in total.

ICT PSP Apollon

20

Final Version

Apollon – Deliverable 2.4 In M16 following the User selection phase and the planning of the first initial round of interviews with the care providing staff, the partner Palmia decided that they would no longer participate in the project due to the    

inability of the Xtramira® to transmit data secure no support for GSM or 3G mobile connection problems with SIP server configuration limited quality of the Camera

Based on this decision two different experiment streams were started.

 The Tunstall / Artic Connect experiment, this is an experiment based on the experiences of the first two phases of the Xtramira® experiment but with a different technology provider. The other local partners, Aalto, Helsinki City Home Care and Forum Virium Helsinki would continue together with Palmia in this spin-off pilot. Utilizing the research methodology and data collection methods derived from the Telesenior Project and configuring the service in a comparable way to the systems utilized in the Belgium Pilot there is a considerable overlap in setup and execution of the project. This makes for comparable material and possible interesting scientific relevant work.

The Xtramira® (v2) project, This is an experiment based on the possibilities that were apparently available with the Xtramira® technology. For this pilot the User groups will be changed to the level where the technology is fully supportive of the needs.

Observed was resistance at the Terveyskeskus Homecare providing staff; some of the Kontula staff, who have expressed concerns that this project does not a) provide enough value to their existing system, b) the technology is not in any way new – and even less so since other municipalities are already using Videra, and c) that their work might actually change into worse when their personal visits are reduced.

In essence they are worried that the social and personal aspect of home care visits would be seriously affected, and the automatization of the system would also make their work ‘less important’. It is therefore now important to really motivate the nurses to participate in the project by explaining them clearly what are the benefits, and what value is gained from this project. Again, therefore it is important to know what’s happening in the other municipalities, to understand better what makes our project special.

The Kontula staff fear that there is also some discrepancy between the agendas of Palmia and Terveyskeskus: the former wishes to expand its market while the latter aims to reduce costs while maintaining and improving quality of the service. The latter is therefore worried that by following Palmia’s ambitions this aim might be endangered. The partners need to express clearly to Terveyskeskus (and Kontula staff), what are their gains.

For the Experiment with Palmia and Televic collaborating in the project setup we were able to achieve these things per party: ICT PSP Apollon

21

Final Version

Apollon – Deliverable 2.4 Partner Televic

type of activity Operational

localization (collaborated with Aalto)

Identifying casespecific requirements

Forum Virium Helsinki

Aalto

Operational

Operational localization collaborated with Televic

Palmia

Operational

Helsinki City

Operational

ICT PSP Apollon

description

transferred 2 devices

info on operation - info provided to set-up the test environment interface translated to Finnish Preparation of documentation Manuals developed

Detecting issues on cross border collaboration and expansion broader then their own pilot was advanced - helped the roadmap

open up the business plan, the current setting Building up the eco-system Giving input to the SME

Providing the SME with market information / access to the players in the market Investigated local protocols/practices

Acquired the needed research permission interface translated to Finnish Preparation of documentation Manuals developed

Experimented with technology provided by Televic

Developed requirements for Local pilot setup Defined User group Definitions 22

Final Version

Apollon – Deliverable 2.4 Home Care

Some lessons learnt per partner were summarized at this point, M16, and used to continue with the two alternative experiments partner Televic

description

Better understanding of the different healthcare / homecare eco systems in Finland and in Belgium

Better knowledge of the different technical environments used by the stakeholders

observed that some initial assumptions (e.g. on technological level) were not correct (e.g. they would have thought that some issues they encountered would not be an issue, e.g. internet connectivity) learnt that listing details are not always easy > this also relates to the issue of adequate information about the service/application

Learnt that the transfer of the knowledge of these details is also not that easy It is important that all stakeholders involved have a good, direct communication to be sure that all info is transferred well There is a different language between parties (customers (FI) versus patients (BE) An R&D project is not the same as a business lead and should be treated in different ways (in terms of expectations, resources....) for pure R&D timeframe of two years is too short

The expectations for both sides needs to be clear: E.g. There is a huge difference between "service" and "product" > product to be changed to the service > service to be changed to the product

On a more strategically level – it was the first time Televic looked to the Nordic countries

Televic learned about the value of good documentation. More attention should be given to the documentation of the products; describing what it can do; what not etc...

ICT PSP Apollon

23

Final Version

Apollon – Deliverable 2.4 Forum Virium Helsinki

we are doing an EU project, the customers are not

> partners, free-of-charge - no way - they need some clear added-value

> Palmia looking for commercial service / Homecare make their work cost-beneficiary > We are interesting in KPI etc... they not

Doing cross border health care projects there is a need for a local partner supporting the technology and the advanced discussions with the partner in the ecosystem. > Living lab alone is not sufficient

> Need for a business development partner / distributor / local organizer Individually the Living Lab cannot take this role (they have no training, no communication) Also local distributor needs training about the service, application... eHealth or Homecare projects are not transferred in the way we have attempted

locally first 'test-labs' need to be built to test the product/service before going to the rollout phase of the pilot

Within APOLLON we are doing a project based exercise and not a commercial track. This implies specific elements to take into consideration Goal is to try out things to see what you can do and by so build up experience to better procure the product Pilots cannot be started or initiated if the benefits of it (of for doing it) are not clear

pilot track and commercial track should be close to each other to ensure a valuable end result for the partners in the experiments

Depending on the type of collaboration or goals, the maturity of the service has to be different. If only a transfer activity is foreseen you need to have already validated services or products, not R&D settings. Only in a partnership where all stakeholders have the same interest in a more R&D specific ICT PSP Apollon

24

Final Version

Apollon – Deliverable 2.4 setting is achievable. But this means that all parties have to be involved from the very early initial proposal stage or project definition

The Economic environment / health service environment has been changed since the proposal. In the current situation a big degradation in the economic situation, the commercial implementation of the service is on a too long term track - not within the year.

Aalto

Either the timing needs to be shorter between proposal and execution or the project needs to be flexible to adjust to the changed environment The local stakeholders (eg. distributor) should be trained & instructed by the SME about the service etc Products should be mature

Technology used local must be tested and validated local

Clarify the expectations of what the technology can do; the proposition has to be clear, starting from a commercial brochure, but not from an R&D or adjusted commercial info Know all actors in the network and have short lines to all partners to insure that the coordination that is important is successful.

Central communication is a necessity, not everyone have the whole project vision . This has to be made clear from the beginning and should be widespread

2.4 Timeline of the Experiment, the XtramiraÂŽ v2 Plan and Engage Phase At the end of M16, after the partner Palmia had decided to withdraw from the XtramiraÂŽ technology the partners in the local network and the cross border partners, IBBT and Televic, discussed the possibility of continuing in a different configuration with a different method of selecting the users, a different method of research and different goals. This basically meant a repeat of the Plan and engage phase.

ICT PSP Apollon

25

Final Version

Apollon – Deliverable 2.4

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

• project redefinition • user selection • research design Figure 5 the Plan and Engage phase

It was decided jointly with Televic that the new pilot would be set up 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. The recruitment was done by Forum Virium Helsinki by contacting a national and the Federation of Hard of Hearing, additionally another group was recruited through personal contacts. The group of elderly people were recruited from a group that has been involved in other projects run by Forum Virium Helsinki.

It was agreed that 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 Lab and an external IT-specialist.

During the in-house testing it was found out that there were several technical shortcomings with the Televic system. The major issue was that it required a non_NAT network with an open IP which is an old-fashion technology and has not been the standard since 1996. Second issue was that the units crashed when opening the connection. Due to instability and that there were no possibilities for the receiving Living Lab to reconfigure the home networks and the present situation would have led to customers’ PCs and other equipment in the network to be vulnerable for attacks and catching viruses, Forum Virium Helsinki and Aalto had to withdraw from the Xtramira pilot

2.5 Timeline of the Experiment, Tunstall; Connect Phase

At the end of M16 the partners Palmia and Helsinki City Health Services proposed to continue with the basic idea of the project and the research as planned but to replace the Xtramira® technology made by Televic with a more advanced technology capable of providing the same service but with the added functionality that is required for the typical Finnish market. This caused a setback in the progress of the experiment and a new connect phase was started.

ICT PSP Apollon

26

Final Version

Apollon – Deliverable 2.4

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

• Search for partners with suitable technology • approach and selection of potential partners • Initial planning of the Project Figure 6 the Connect Phase

The need for a different technology started a search for possible solutions. There were two candidate systems that were suitable for the customer requirements.

The Tunstall / Arctic Connect System, and the Videra home care system. The two systems were suited for simultaneous testing of solutions, including the technical aspects of the project and the social benefits that they can provide to the participants in the experiment. Both systems were to be tested with up to 10 home care clients.

The Tunstall/Artic Connect system

The system will integrate the home alarm function and the audio-visual line and it will be provided for up to 10 clients. With this pilot the customer on the system is participating with their consent and ensured of the protection of their privacy. Helsinki City Home Care selects at the start of the pilot phase the customers, so that they represent different groups of customers, such as older and younger chronically sick, demented, or disabled, or other home care clients that use, or have benefit from using such system. Predominantly the customers are those who already have a Tunstall alarm system. The pilot phase will last 6 months. Below is the technical description of the surroundings.

ICT PSP Apollon

27

Final Version

Apollon – Deliverable 2.4

Figure 7 Tunstall System Environment

The Videra system

Similarly, A test will be run using the Videra system. Although the Videra system does not integrate the home alarm function, from the perspective of Helsinki City Home Care, the functionality is comparable to the Tunstall/Arctic Connect system. Below is the technical description of the Videra environment.

Figure 8 the Videra Technical Environment.

ICT PSP Apollon

28

Final Version

Apollon – Deliverable 2.4 Both pilot designs aim to examine the use of audio-visual technology to establish a video connection to the customer's home. In the pilot study the use of video equipment to support opportunities for home care of the daily operational models, such as reminders for taking medicines or other treatment follow-up routines. The Video Connection with Tunstall/Arctic Connect system is hoped to boost alarm assessment and more accurate and appropriate response without need for deployment separately of an ambulance attendant, customer-dependent alarm by pressing the alarm button opens a connection to the emergency service, which is to facilitate communication with the customer. The Video connection is also expected to improve the overall customer communication for home care professionals, as well as the client's with some of his/her own close friends.

After a series of discussions the first technology to be tested in the local environment of Forum Virium Helsinki and the Helsinki City Home Care is the Tunstall technology.

The main participants in the project were the Helsinki City Home Care, Palmia, Tunstall, Arctic Connect and the customers. This was completed by an outer circle of management and support organizations, Forum Virium Helsinki and Aalto CKIR. Helsinki City Home Care was the in charge of providing homecare clients in the trial project. The pilot operated in Kontula 1 and Kontula 2 Home Care units. Palmia is a private company owned by Helsinki City. Helsinki is Palmia’s main customer. The role of Palmia in the project was central; they were running the helpdesk, the servers, the hardware and software installation for the experimental trial. Palmia was also the provider of the emergency service, and envisioned provider of the virtual home care service through their virtual contact centre in the future, should the solution be finalized and implemented in large scale. Tunstall provided the hardware and software for the project.

The project started with an extensive analysis of the as is situation in Helsinki Home Care services. For the pilot, the various roles enabling the new service were defined as enablers, users, developers and analysers. After that, the technical and organisational requirements, as well as aspects related to security and privacy were assessed in detail. This process took surprisingly long, and numerous challenges and obstacles surfaced in the process, both in terms of technical as well as organizational aspects. With this, the actors for the various roles were selected, and the more detailed project planning was kicked off.

Commitment from the ordering party, the City of Helsinki, was ensured by involving high level authorities in the project steering group, and keeping the management of the City health care services regularly updated on the project developments.

However, the Videra pilot was never rolled out. The reason for this was the fact that the technology provider did not meet the arrangements and schedule that was jointly agreed. Hence, the Helsinki City Home Care decided that they will only continue with one system: Tunstall/Arctic Connect.

ICT PSP Apollon

29

Final Version

Apollon – Deliverable 2.4

2.6 Timeline of the Experiment, The plan and engage phase The video connection as such is a mature technology, used widely in video conferencing and remote health care. However, it has not been previously used in home care settings combining both the health care and emergency services.

Also the two-way communication where the customer can also contact the health care provider at their convenience is a novel set up. The experiment was conducted in a real life environment, applying co-creation methodology, where all participating actors together contributed to the development and improvements of the service

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

• setup of the local experiment • user selection • localization of technology Figure 9 the Plan and Engage Phase

In the pilot, the Helsinki City Home Care selected 10 pilot users with different profiles from their customer base in the areas of Kontula 1 and Kontula 2. The selected clients were between 50-90 years old, representing different profiles in terms of their independency and health. An individual set of objectives was defined for each customer. The objectives ranged from supporting drug-free life style and increased independency through social interaction, to reduction of regular visit through reminders of medication and meals, as well as simple care operations like taking medicine and measuring blood pressure.

In the course of pilot, new aspects like improved sense of security and confidence to live independently were also detected. The system was further integrated to the emergency response system that the customers had subscribed to, operated by Helsinki owned service provider Palmia. Palmia is the principle supplier of the ICT and phone related health services for the City of Helsinki. The emergency service system included an emergency button that the customer could use in case of emergencies to receive immediate help. In the project, push of the button activated a video connection to the Palmia virtual care centre, and this supported the call-centre personnel to make a more comprehensive assessment of the situation, respond to the needs more accurately than currently, when the push of the button triggers only a voice connection to the virtual home care centre of the nurses’ call rink.

The pilot introduced a novel virtual care solution that was considered to add value to the customer. Simultaneously, the pilot served as a platform to simulate integrated service delivery by the Helsinki City Home Care and Palmia. Increased virtual care is a strategic choice for Helsinki, and the pilot simulated a situation where a virtual component was introduced to the home care solution by Helsinki ICT PSP Apollon

30

Final Version

Apollon – Deliverable 2.4 City Home Care, and delivered seamlessly together with the emergency response service, operated by Palmia. This enabled the planning and analysis of the structures, roles and processes that would need to change as the service was introduced in broader scale.

The project focused on costs, technical challenges and information exchange in the service delivery ecosystem, without consideration of the cultural and institutional changes that the collaboration resulted in the participating organizations.

2.7 Timeline of the Experiment, the Support and Govern Phase Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

• running of the experiment • collecting all the research data Figure 10 the Support and Govern Phase

The material collected in the interpretive analysis included documents, reports and participatory observations of the development and critical incidents in the preparation of the pilot. During the actual case pilot, the data was collected in structured interviews with the involved customers, nurses and supervisors at Helsinki City Home Care and Palmia. Altogether 20 interviews were conducted.

The interview data was complemented with web-based survey that was responded by 17 nurses from the area, as well as quantitative analysis of the monthly computer logs and reports that were compiled of each call on monthly bases. The average number of calls per month was around 200 calls, resulting overall in over 1000 calls in the studied period of 5 months

2.8 Timeline of the Experiment, Manage and Track Phase

Connect:

Support and Govern:

Plan and Engage:

Manage and Track: • Data analysis • Conclusions

Figure 11 the Manage and Track Phase

The analysis of the data was conducted following the case study methodology.

Triangulation of the data through various sources ensured the reliability of the results, while the internal validity was ensured through selection of reliable and closely involved data sources. External validity was ensured by a selection of a representative case, and thorough analysis of the operating context for ICT PSP Apollon

31

Final Version

Apollon – Deliverable 2.4 generalization. Inference typical to case studies (Yin, 1989, 43) was overcome by direct participatory observations of the case. The data was categorized applying a grounded theoretical framework that ensured the relevance and linked the analysis to a broader discussion in the field.

The research design was built on two main research questions that carried on the activity and research:

1) What are the perceived impacts of the video connection to the various parties involved?

2) What are the anticipated system level changes required for the wider implementation of the service?

The first question regarding the direct impacts and benefits of the new service component to the various stakeholders was mapped through structured interviews, web based surveys and computer logs for quantitative evidence to support the interview data. The analysis was fairly simple since virtually all collected evidence suggested the similar values and experiences. The customers felt that the video connection brought a value adding component to their daily care. The technology was non-invasive, easy to use, and added to their sense of confidence to act and live independently through increased sense of security, connectivity and access to the aid personnel. The connection provided much appreciated social interaction at the customers’ convenience, while not invading their privacy or daily schedules.

In terms of clients, they reported increased confidence in their ability to live independently, as well as enhanced sense of personal security as the main benefits of the system. The social interaction was considered as the second main benefit. The customer interface is a touch screen solution installed in a convenient, accessible place in the customers’ houses. All interviewers described the technology as easy to use and non-obstructive. None of the customers had any challenges with the use of technology. Furthermore, the customers did not report any objections or hesitance in talking to the nurse over the video connection compared to their personal visit. This can be explained partly by the familiarity of the persons involved, as well as the fact that the scheduled daily visits still continued, and with that the video conversations only partially replaced the physical visits.

The log files demonstrated steady increase in the both number and duration of the calls, which indicates that with time and familiarity with the technology, its’ use is internalized and it becomes a routine part of the care service. Especially encouraging finding was the fact that the customers began to increasingly initiate the calls themselves. The reasons for the call, as documented in the Pegasos system used by Home Care, were predominantly reminders of medications and meals, as well as generic check-ups on the general condition and well-being of the customer.

The nurses seconded the ease of use of the system, and felt the added value in terms of increased informal communications with the customer, which was considered to contribute to preventative care, With the system the nurses had a ICT PSP Apollon

32

Final Version

Apollon – Deliverable 2.4 better overall knowledge of the customers’ status both physically and mentally, and could address issues before they escalate to an extent that other unplanned visits would be needed. However, the nurses felt that the system provides a nice addition to the existing care, but does not enable reduction of too many regular visits. During the pilot the system was realized to suit better support for daily activity, rather than handle health related care operations remotely. In any case, for some of the pilot customers, a part of the daily visits were replaced by a call.

For the technology provider the pilot provided valuable input to the product development in home care context. The system had been remotely used in professional setting between heath care centers, but operating it directly with end customers in home environments added to the complexity of the set up and use. Also the integration of the care and emergency response services in a single set up was an novel feature in the set up. The feedback was collected from all user groups. The customers’ feedback was predominantly related to the sounds and the lights in the screen, and thus related more to the usability of the system than to the functional features. The first change made was a louder and deeper sound for the calls, as well as longer duration of the activated ringing. Also the lights of the system in a stand by position were changed in order not to have a bright, disturbing reflection in the room when not operational. The nurses’ feedback centered around the functionality and integration to the existing systems. The recording of the calls needed to be made in a separate system, and thus system integration was called for. Further, the nurses had ideas about integrating other care functionalities to the virtual care.

The nurses at the emergency response center considered the system as a valuable add to their response service. The current system was not integrated in the event log system, and with that even a stand-alone system provided significant improvement to the situation. The system enabled receiving several calls simultaneously, and forwarding them to nurses in order of priority and criticality. The video link further enabled immediate contact with the patients, which typically have to wait a while after the call before the help arrives.

Through the visual connection the nurse can ensure the customer that help in on its’ way, and provide immediate assistance and support virtually.

The impacts to the case owner, the City of Helsinki as the responsible health care provider were many-fold, and constitute a system level change that was a focus of the research question two. The case provided a representative example of a system level innovation project. The introduction of the ICT component resulted in numerous changes and adjustments in the processes, roles and mandates of the various actors. The need for further integration of the various dimensions of the service became apparent, since the current information systems at Home Care and Palmia emergency services were not integrated, and the virtual care system operated in the both systems’ interface. With this, the nurses responsible for the care should have full visibility and access to all information and incidents that happened to their customers. However, this is not the case currently, and the knowledge exchange relies on informal phone calls between the care personnel. Further to the knowledge systems, also the operating processes require adjustments.

ICT PSP Apollon

33

Final Version

Apollon – Deliverable 2.4

2.9 Outcomes on the pilot level In the pilot, the challenges in this front began already at the system set up, since the motivations and objectives of the participating organisations did not fully meet. This brings challenges in customer selection and delays in system installations. Even the technology provider needed to be changed due to the different expectations in terms of the technical and functional specifications of the system, e.g. redundant connection for security, encryption for protecting the data flow, and higher resolution camera for care operations. The objectives and purposes for the system needed to be re-negotiated numerous times in order to find consent on the operation, communications and customer interface management. In the end, the Helsinki City Home Care took the main responsibility of running the pilot operationally, as the owner of the customers, and responsible for the main body of services in the scope of the pilot. During the pilot the technical issues were easily dealt with, and the main body of work concentrated on process integration and finding care operations in which the system would yield maximum benefits. Since the video connection was not a service per se, but rather an enabler for a range of other services, the integrative nature of the system required adjustments and profound changes in the means that the overall care service and emergency response service were defined and the roles in providing them were defined.

This highlights the social constructivism of technology, and the complex relations between the actors in the service delivery network. The integration of the previously separately provided service components also revealed the demand for careful consideration of the numerous actors in the network. Also, it focused on the different characteristics of the relationships and their coexistence and evolution in the network. As such the case further build on the notion that quantitative macro level analysis alone cannot explain the success or failure of the systems, but instead, qualitative micro level analysis is required for the analysis of the system determinants. The studied pilot case is in a state where the experimental pilot is over, and the system is put in production.

Essentially this means that the system is transferred operationally to the envisioned service delivery point at a virtual care center, and the new operational processes and the system functionality are tested further with a broader customer base.

2.10 Lessons learned on the pilot level

The case further provided evidence for an interesting analysis on the change in the institutional logic of providing services. The described process took place during the pilot project, where the professionally constructed logic in the Home Care service delivery was about to change to a n efficiency driven logic, where the various motivations, norms, cultures and identities of the participating actors would have been embedded. This was an incremental and multifaceted process, and partly explains the delays and challenges experienced in the pilot preparation and set up phase. The service was delivered in a multi-actor network that enabled servicing a broader customer base. This is a significant change in terms on the traditional Home Care services; where by the prevailing ICT PSP Apollon

34

Final Version

Apollon – Deliverable 2.4 institutional logic is based on strong professionalism, health care expertise, and identity of the nurses in the care service providing organizations. In collaborative service creation might exist several competing institutional logics, and they all should fit in together under a higher, system level logic, which is partly composed of the lower level arrangements and solutions. The service created is the common nominator, which binds the different organizations together for increase efficiency.

ICT PSP Apollon

35

Final Version

Apollon – Deliverable 2.4

3. Pilots of wp2: Dutch-Spanish experiment The following section chronologically describes the activities that have taken place within the Dutch-Spanish experiment in WP2 devoted to the transfer of Innoviting’s ADL system to Andalusia for piloting with relevant users. An extensive description of the experiment is provided in D2.3.

3.1 Description of the Experiment

The ADL system is an intelligent home automation application for the elderly.

The system uses small wireless sensors capable of recognizing the behavior of residents’ daily activities. The sensory input is fed into a system that is thus capable of monitoring the behaviour. When the system detects an abnormality in the daily routine it will alert family, neighbour or a caregiver. The ADL system makes it possible monitor elderly people in their homes while maintaining quality of life and improving safety so that the clients of the system are capable of living independently longer.

The business model in the Netherlands is to sell it directly to consumers without reimbursement of the government or insurance. In the Netherlands the system is providing “peace of mind” for relatives and the elderly.

In the Netherlands there have been two types of pilots; the “Naarderheem” pilot in a closed department for elderly with dementia. INNOVITING installed the ADL system in 5 rooms. The caregivers could see the behaviour of the elderly. For the alarms there were 3 danger levels, out of bet, out of the room, not back in the room within a certain time.

During the day there is enough personal to check on the elderly, but during the night there is not enough personal available. The night personal walks rounds to check up on the elderly, the night personal founds the ADL system interesting but to be honest they didn’t see much they already know. The personal lives with all the elderly for such a long time and know exactly when something is wrong and needs more attention.

In The Netherlands there are 10 houses equipped with the ADL system. This is done in two waves of 5 people for a period of 4 months each. The elderly and family where found via colleagues and a local home care party called “Steunpunt Mantelzorg”. For each elderly there where one or two family members who worked with the system, in practice we noticed there is only one family member head of the system, the rest of the family follows his or hers orders. Including the elderly we had 25 end users who were involved with the ADL pilot in The Netherlands.

When this pilot was finished INNOVITING noticed that this was not going to be a vital business case. The aim for the pilot was to reduce the staff during the night and this was not going to happen. There has been a change in direction, the focus of the product changed to home care and family of the elderly. The business ICT PSP Apollon

36

Final Version

Apollon – Deliverable 2.4 model is to sell it directly to consumers without reimbursement of the government or insurance. Not that we don’t want it but it’s too complex and full of change. It will take a lot of time and money to arrange such a reimbursement.

Our thought is that the system must be good enough, give so much advantages that you would buy it with your own money. If our system gets regulated that’s a great discount for the consumer. And will make it easier for us to sell.

In the Andalusia region (wellbeing services are completely devolved to the regional authorities in Spain) almost all elderly assistive technologies are provided to the target demographic by public agencies and government entities, but we also view that this system could be made available via open commercial channels. The regulatory hurdles and lag times if a public provision scheme was sought would put the effort well outside the time-scope of the project.

3.2 Timeline of the Experiment, the Connect Phase

The initial phase of the experiment: where the first analysis of the local ecosystem for the product/service offering has been done. This Analysis showed several potential ways to approach the experiment with various partners. Both SMEs and the local Wellbeing agency were approached and choices were made in the setup of the local network for the Living lab experiment.

Connect:

Support and Govern:

Plan and Engage:

Manage and Track:

• Initial planning and coordinating activities • Identification of requierments • Analysis of Ecosystem • Search and approach of potential partners Figure 12 the Connect Phase

M1-M6 The first period was devoted to initial planning and coordination activities.

The main areas of action in this period were: • •

Identification of requirements Ecosystem analysis

The identification of requirements for this experiment included aspects such as a detailed description of the technology and elements of the system, technical setup, installation requirements and support and help-desk structure. Several three way (AIM, Innoviting and IAVANTE) videoconferences were held to round up ICT PSP Apollon

37

Final Version

Apollon – Deliverable 2.4 and package this knowledge and transfer it to the remote living lab (IAV). This information was registered in Deliverable 2.1 Regarding the analysis of the remote ecosystem (meaning the Andalusian context of the pilot), the process followed the guidelines written down in Deliverable 2.2 (Common Living Lab Approach). Relevant information on the following aspects of the ecosystem was conveyed to the Dutch partners in the experiment: • •

• •

Agents/stakeholders (users, care-givers, emergency services…)

Institutions (social services agencies, technology providers, the health system at large) Regulations (privacy laws, patient rights laws, law for dependent people) Other (cultural issues etc.)

This ecosystem characterization was simultaneous with IAVANTE’s effort to get relevant stakeholders involved in different capacities in this APOLLON experiment. To that end, IAVANTE, as the managing partner of Living Lab Salud Andalucía made a presentation about the APOLLON project in its annual member assembly in late 2009 to all the living lab members (44 entities at the time, 99 at the time of this writing).

IAVANTE identified several key members (SMEs and the main social services agency in the region) who were contacted individually to request their participation following the guidelines for such action established in Living Lab Salud Andalucia’s working rules (http://livinglabsalud.es/llsa/normas/ link in Spanish).

Libera Networks, Hispateca, Aliatis and InfoEs were the SMEs that IAVANTE found could be interested because of their focus on wireless communications and information systems.

All four companies expressed their interest in the experiment and found the description of the technology to be within their areas of expertise, where they could have meaningful contributions to the project. Unfortunately, in all four cases, the SMEs declined to formally participate as associated partners in the experiment due to financial constraints at the time.

IAVANTE also engaged the Andalusian Foundation for Social Services (FASS, currently in the process of being integrated into the Andalusian Wellbeing Agency), a regional government foundation that is, by a wide margin, the largest provider of assistive services for elderly and dependent people in the region with thousands of subscribers to its tele-assistance service.

FASS also showed interest in the technology and services deployed in this APOLLON experiment and, as part of their general collaboration activities with Living Lab Salud Andalucia, accepted to collaborate with IAVANTE in the experiment. They started their involvement with a consulting role focused on user search and selection for the piloting stage (work began at M10).

The following graph provides an overview of the local ecosystem for the ADL pilot in Andalusia:

ICT PSP Apollon

38

Final Version

Apollon – Deliverable 2.4

Figure 13 Ecosystem Spanish Experiment

3.3 Timeline of the Experiment, the Plan and Engage Phase The second phase of the experiment: where the localization activities and the user selection are done. The local circumstances and the progressing technology made for changes in the setup of the experiment. The methods for gathering the research data were chosen and a test setup at the controlled environment at the premise of the Living Lab was made. In this phase many lessons on the capabilities and functionality of the technology as well as on the context to where the technology is transferred to is learned.

Connect:

Support and Govern:

Plan and Engage:

Manage and Track:

•Research setup and research methods •User selection criteria •Technology transfer and localization •Testing service in controlled environment •Detailled planning of execution of experiment

ICT PSP Apollon

39

Final Version

Apollon – Deliverable 2.4 Figure 14 the Plan and Engage Phase

M7-M9 Research Set-up: the research-set up discussions focused on defining the main research goals (“what do we want to learn from the experiment the most?”) the basic tools for data collection and analysis (questionnaires, interviews, etc.) and identifying the responsible persons for such effort within each of the partners involved in the experiment.

There was a delay in M10-M12 against the original planning because it was deemed desirable to wait until a newer version of Innoviting’s ADL system (with improvements in user interface and system reliability) was ready for deployment.

The ADL hardware has been change to other hardware. The hardware needed less functionality, easier to install and be cheaper. We found a vendor in Taiwan who could also adjust some parts for our specific needs. For each house 7 sensors (3x movement, 2x door, 1x message pendant) and a modem is installed.

The application got an upgrade in the interface. Their family has totally different needs; they are more interested in the daily activities then the long term trends.

In M12 the experiment partners decided to modify the planned structure of the piloting. Due to some constrains on the availability of ADL kits from Innoviting and the realization that most of the valuable and significant feedback from users of the system comes early in the usage of the service, it was decided that the 15 user deployments would take place in 3 two-month waves with 5 users each.

This entailed a more complex deployment for IAVANTE but it was deemed feasible and the pilot was re-scheduled according to this new structure.

M13 was devoted to the completion of the technical transfer of the ADL technology and service from Innoviting to IAVANTE. Innoviting produced and provided IAVANTE with detailed documentation on the ADL system, including: • • • • •

•

System architecture System administration Technical configuration of the user home gateway System installation Practical guide on sensor installation depending on architectural and layout constraints.

User guide and description of the interface

A representative from Innoviting (Tim van den Dool) travelled to Malaga for a face to face meeting with IAVANTE’s technical team involved in the pilot effort (December 16th 2010).

During M13-M14 IAVANTE and Innoviting worked in adapting the ADL system to function within a public regional messaging platform for caregiver alerts (SMS) to which IAVANTE has access. A technical solution was found and tested but in the end Innoviting decided that their current platform was cost-effective enough and that the cost difference was not worth the technical change.

January and February 2011 (M14-M15) were devoted to technical and functional testing of the ADL system in the remote environment. This test environment in the local environment under controlled circumstances is an ICT PSP Apollon

40

Final Version

Apollon – Deliverable 2.4 important step in the setup of the product/service experiment that provides experiences and tests the entire network of the service delivery. During this test potential problems that may arise in the field trial can be discovered and resolved.

IAVANTE was provided by Innoviting with a complete ADL kit and installed it in a simulated elderly person house in its Granada simulation centre (CMAT).

These are some pictures from the installation:

Figure 15 Location of sensors in test setup

IAVANTE follows a structured approach to testing, derived mostly from its software engineering experience. This includes unit testing and usability testing.

From the technical point of view, tests were performed on several key areas.

Connectivity

Bandwidth requirements; the different sensors have these data parameters: • • •

Heartbeat (30 bytes every 5 minutes) Door sensor (294 bytes per activation) Motion sensor (294 bytes per activation)

Average data consumption for normal use was assessed at around 281 kilobytes per day with the following usage profile: • • •

• • •

Bathroom: once a day, 15 minutes (one activation per minute). 4.3 kilobytes Toilet: 3 times a day. 1.72 kilobytes Kitchen: 3 times a day for 30 minutes (one activation per minute). 25.83 kilobytes Living room: 8 hours a day (one activation per minute). 137.81 kilobytes Bedroom: 6 hours a day (one activation per minute). 103.35 kilobytes Heartbeat: 8.43 kilobytes

ICT PSP Apollon

41

Final Version

Apollon – Deliverable 2.4 This results in a total data usage of around 8 megabytes per month.

The SMS service was tested for Spanish phone numbers for delay and data encoding. There were no problems detected.

Fault tolerance

The system was tested for recovery from power loss, connectivity loss (either one of the channels or both) and communications redundancy (switching from wired Ethernet connection to GSM data link) and local (i.e. at the home gateway) data caching during communication loss.

Sensor installation

Tests were carried for signal loss with sensor distance, architectural obstacles (columns, load bearing walls, electrical pathways) and nearby appliances (fridge, TV, microwave). Tests confirmed the general installation guidelines provided by Innoviting.

Configuration and administration

Several key elements about the home gateway set-up were tested and practiced

by IAVANTE’s technical team: • • • •

Sensor pairing and assignment to corresponding room.

User ID gateway configurations.

GSM SIM card set-up in the home gateway.

Communications configuration.

A feedback document with technical testing findings produced by IAVANTE was shared with Innoviting.

In M14 IAVANTE held a meeting with FASS to receive valuable input and advice on user selection. Starting with the target demographic profile provided by Innoviting:  elderly people living alone,  close to the point where they won’t be able to live independently anymore  in need of frequent family support visits

Based on these criteria FASS provided a list of potential candidates.

In addition to that, FASS provided IAVANTE with a set of recommendations for engaging these potential candidates and for dealing with the actual contacts for installation of the ADL system in their homes once they accepted to be involved.

Among these recommendations were: • •

Wait until as close to the actual pilot start date as possible before contacting the users. This greatly reduces attrition. If too long a time passes since user agrees to participate until actual pilot begins, many people back down by then.

Make sure it’s not just a technical person who will go to their homes to install the system. Every contact should include a person who is capable of explaining every aspect of the pilot and the philosophy of the service to the user.

M13-M14 is also the period where the main translation and local adaptation tasks were performed. Translation was done in a dual process. Innoviting ICT PSP Apollon

42

Final Version

Apollon – Deliverable 2.4 contributed a full translation of the whole system interface into English and IAVANTE performed the corresponding translation from English into Spanish.

Technical documents that were only needed for installation and set-up of the system by IAVANTE’s technical team were not translated into Spanish.

Translation required some modifications to the original meanings due to the differences in the pilot perspective in Andalusia compared to the previous pilots in the Netherlands. For example, the user-activated button was considered an emergency alert in the Dutch pilots but was treated as a simple “poke” or “call me” message in the Andalusian pilot.

Original translation from Dutch was performed by machine translation and further refined by the Innoviting team. IAVANTE’s linguistic services department performed translation from English to Spanish. This department has a long experience in the translation of both interfaces and literature focused on healthcare and wellbeing topics for both the regional government in Andalusia as well as European scale projects.

During M16-M18 efforts were focused on usability testing. This was a twopronged task: on one side, functional testing of the different configuration parameters of the service interface were evaluated and checked for consistency and optimal values; on the other side, user-centred interaction testing of the system interface.

Functional testing focused specially on the configuration parameters for the ADL (user) Web interface and alert system (SMS messaging and e-mail notifications).

The system allows for setting up different time intervals before triggering an alert message. This is configured separately for each sensor/room element.

IAVANTE tested several profiles for these room-specific triggers and the most efficient mechanism for notification in each case (SMS, e-mail or no notification).

Several usability issues were detected in the messaging policies and were reported back and promptly addressed by Innoviting technical team. The main issues found were: •

• •

Sensor tampering detector (spring button on the back of the PIR sensor) has a too high frequency pooling and messages were sent for each detection. So, a sensor falling from its position or being repositioned voluntarily could easily generate dozens of user messages instead of only one.

“Call me” sensor can send up to 4 messages on a single activation.

Some of the night/day inactivity time trigger parameters were not working as expected.

The interface testing centred on the ease of use and service self-discovery for people with basic computer skills. Conclusions from these tasks provided useful feedback for retouching some translation elements and explicative texts.

For this action, an ADL kit was installed in a real environment (not simulated) with a friendly user (i.e. known and close to the people managing the project) to gather more effective feedback on actual life-like behavioural and movement patterns.

At the same time, browser compatibility was tested extensively (Internet Explorer versions 6 and 7, Mozilla Firefox version 3.6, Apple Safari version 5, ICT PSP Apollon

43

Final Version

Apollon – Deliverable 2.4 Google Chrome, Opera). Feedback on browser compatibility findings was provided to Innoviting.

Improvements to the service and changes in the user interface performed during these months produced some usability regressions on the service and had to be corrected before the pilot could begin. To start the actual pilot in the three waves a number of preparation activities were done.

Preparation activities include:    

User selection (search, contact and engagement, agreement and informed consent).

Informative session with the caregivers that will be participating in the pilot to describe the functionality of the service and how to make use of it.

Specific configuration of the devices (home gateway, user permissions in the administration portal, sensor pairing).

Basic testing of the set-up in IAVANTE’s facilities before installation

There was also additional functionality introduced in the service (long term – weekly, monthly- patterns providing averages and trends for activity) that required additional adaptation and translation work. These issues postponed the beginning of the pilot by approximately two months. Deployments, thus, began for the first wave of users on M23.

3.4 Timeline of the Experiment, the Support and Govern Phase During the third phase of the experiment the realization of the experiment takes place. The technology is utilized in the daily life of the participants in the project and the data for the research component is gathered. The three waves of installations and application were completed in this phase. The support from the technology provider is limited.

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

• Installation in real environments with users • Deployment of technology and service • Data gathering

Figure 16 the Support and Govern Phase

ICT PSP Apollon

44

Final Version

Apollon – Deliverable 2.4 User search and engagement for the three pilot waves took place, respectively, at M21, M24 and M26. This is explained with more detail further along the document.

Final details on the deployment plan (main tasks for each wave, overlapping activities between pilot waves, etc.) and structure of the research effort (final form of the questionnaire, timing for the interviews and feedback gathering process, etc.) were finalized in M16-M18. This involved several teleconferences between IAVANTE, AIM and Innoviting and a face-to-face meeting in Malaga between IAVANTE and Innoviting (May 13th 2011, M18). The final version of the questionnaire (original written in English) was translated to Spanish.

The following outline provides a summary of the topics addressed in the caregiver questionnaire that they fill after using the system. There are three basic areas of interest to characterize the situation, needs and potential interest in specific tools or solutions that the caregiver may be willing to pay for.

•

Demographics / Current situation: o o o o

•

Problems and needs: o o o o

•

Age of the target user Relationship with the caregiver Requirements availability Existing services (professional help, allowances for informal caregiver…)

Time devoted to providing care What is the experience of providing care like? (Have enough time for it?

How do you feel about the task? Etc.) Commuting needs, frequency of visits, length of visits.

Main worry elements:  Personal hygiene  Illnesses or emergencies  Food intake  Medical treatment adherence  Security  Loneliness / social contact

Features and added value: o o

ICT PSP Apollon

What other assistive elements are available in the elderly person home Which aspects of daily life would you want to be alerted about with the system  Emergencies  Sleep problems  Reductions in daily mobility/exercise  Suspicious inactivity / falls  Night outings 45

Final Version

Apollon – Deliverable 2.4

o o o o o

 Inadequate hygiene  Fire and gas detection How much would such a system lighten your current care burden?

Would it reduce your current level of worry?

Would it reduce the frequency of your visits?

Do you feel you’d be providing better care with such a system?

Would you be willing to pay for the service? (Estimation of costs is provided)

Structure of the pilot As mentioned before, the pilot for a total of fifteen elderly users was structured in three sequential waves with five users participating in each of the waves.

A wave lasts for two months for proper piloting. All the necessary preparation activities are carried before this two-month period (i.e. overlapping with the previous wave in all but the first one).

Once these activities have been finished, the system is finally installed in the user home for a period of around two months (8 weeks).

Installations are always done with two persons from team present (a technician and a project representative with knowledge of all the non-technical surrounding issues). Installation requires, in addition to the rather straightforward technical tasks, a lot of reassurances and explanations to the user. It doesn’t matter how detailed and simple the information in the consent document is, users always hold many doubts and fears about privacy and safety.

For all the duration of the pilot, users and caregivers have a 24/7 available contact point (phone number and e-mail address) for any technical (or other kind of) issue that may arise. The section on pilot outcomes describes the activity that took place in this area.

After four weeks of service usage, caregivers are invited to a meeting (focus group) to discuss their current experience with the system. The meetings have a very open structure and are essentially a conversation between users about their principal uses for the system, issues they have discovered, surprising insights they didn’t expect to get from the system and similar topics.

Just after the end of the eight week pilot period, the caregivers participate again in a meeting similar to the one described in the previous paragraph to see the evolution of their views once they’ve gone from the very initial period where they’re still getting familiar with the system to a point where they feel confident in their knowledge of the service, its features and options.

During this second encounter they also fill the previously described feedback questionnaire.

The pilot has taken from M23 (first wave deployment in the second week of September 2011) to M28 (Second week of February 2011 end of the third wave).

First wave (M23-M24) ICT PSP Apollon

46

Final Version

Apollon – Deliverable 2.4 User selection took place during M21. Target groups were the contact list provided by FASS and an internal search for the required profiles run within IAVANTE’s employee portal (looking for family members, acquaintances, neighbours, etc.).

Initially there were interested users in Malaga and Granada but some Granada users backed down and it was deemed more efficient to run the whole experiment with users in Malaga.

Deployment took place in M23 week 2 (September 5th-9th) for the five users in the Malaga metropolitan area.

User ID Age Gender 1.1

74

1.3

71

1.2 1.4 1.5

Main caregiver

Malaga

Daughter

Male

Fuengirola

Female

Malaga

77

Female

79

Male

70

Location

Male

Table 1 First Wave Users

Torremolinos Malaga

Son in law Son

Niece

Daughter

User 1.4 decided to leave the pilot after 8 days of use, due to concerns about privacy. The rest, stayed in the pilot until the end of the wave (First week of November 2011, M25) Meetings with the caregivers took place on October 10th and November 7th 2011.

Information on the number of issues (calls, support e-mails and visits other than installation and withdrawal of the ADL kits) for the three waves is provided in the section on outcomes of the pilot.

Second wave (M25-M26)

User selection took place during M24. Target groups were the contact list provided by FASS. All users are from Malaga metropolitan area. Installations took place on the second week of November 2011 (7th-11th) These are the profiles for the second wave User ID Age Gender

Main caregiver

Malaga

Daughter

2.1

72

Female

2.3

69

Female

81

Female Benalmadena

2.2 2.4 2.5

72 76

Male

Female

Table 2 Second Wave Users

ICT PSP Apollon

Location Malaga Malaga Malaga

47

Daughter Son

Daughter Nephew

Final Version

Apollon – Deliverable 2.4 All five users stayed in the pilot until the end of the wave on third week of December 2011 (M26 19th-23rd).

Meetings with the caregivers took place on December 12th 2011 and January 9th 2012 (delay due to scheduling problems during the holiday problem to get all participants).

Third wave (M27-M28)

User selection took place during M26. Target groups were the contact list provided by FASS. All users are from Malaga metropolitan area. Installations took place on the fourth week of December 2011 (27th-30th) These are the profiles for the third wave User ID Age Gender

Location

Main caregiver

Male

Torremolinos

Daughter

Female

Malaga

Daughter in law

3.1

80

Male

3.3

74

Female

71

Female

3.2 3.4 3.5

70 75

Table 3 Third Wave Users

Malaga

Churriana Malaga

Son

Daughter Niece

All five users stayed in the pilot until the end of the wave on second week of February 2012 (M28 13th-17th).

Meetings with the caregivers took place on January 27th 2012 and February

The locations of the installations for three waves are presented in the following map (first wave is blue, second is green and third is yellow):

Figure 17 Locations of the Users

ICT PSP Apollon

48

Final Version

Apollon – Deliverable 2.4 After the installation process we took pictures of the installed sensors in the users homes (in the cases where the users gave their explicit consent). The following pages provide some examples:

Figure 18 Location of Sensors in the House

3.5 Timeline of the Experiment, the Manage and Track phase In the last phase of the experiment the results of the experiment are analysed and distributed to all the relevant stakeholders.

ICT PSP Apollon

49

Final Version

Apollon – Deliverable 2.4 Connect:

Support and Govern:

Plan and Engage:

Manage and Track: • Analysis of gathered data • Dissemination of lessens learned • Planning of further experiments

Figure 19 Manage and Track phase

As mentioned above, a total of 15 elderly users have participated in the three pilot waves. In most cases only one caregiver was making use of the service, but some cases have had 2 and 3 different caregivers accessing the service.

User ID Age Gender 1.1

74

1.3

71

1.2 1.4 1.5 2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.4 ICT PSP Apollon

Location

Main caregiver

Malaga

Daughter

Male

Fuengirola

Female

Malaga

77

Female

79

Male

Torremolinos

72

Female

Malaga

69

Female

81

Female Benalmadena

70 72 76 80 70 74 75

Male Male

Female Male

Son in law Son

Niece

Malaga

Daughter

Malaga

Daughter

Daughter

Malaga

Son

Malaga

Daughter

Malaga

Son

Nephew

Male

Torremolinos

Daughter

Female

Malaga

Daughter in law

Female

Churriana

50

Daughter

Number of caregivers 1 1 2 1 1 2 2 1 3 1 1 1 1 2

Final Version

Apollon – Deliverable 2.4 3.5

71

Female

Table 4 Overview of End Users

Malaga

Niece

1

Consequently, the total number of end users involved in the pilot is 36 (15 elderly people and 21 family caregivers).

Regarding the number of contacts that took place with each of the participating users (both elderly people and caregivers) the following table provides a summary (installation and removal visits are excluded as well as calls initiated

by IAVANTE for scheduling meetings and so on): User ID Age Gender 1.1

74

1.3

71

1.2 1.4 1.5 2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5

Location

Male

Fuengirola

Female

Malaga

77

Female

79

Male

Torremolinos

72

Female

Malaga

69

Female

81

Female Benalmadena

70 72 76 80 70

Male Male

Female Male

Malaga Malaga Malaga Malaga Malaga

Malaga

Female

3

1

4 2 9 0

3

Female

71

Visits

2

Torremolinos

Female

Calls

5

Male

74 75

Malaga

Elderly person

Churriana Malaga

1 3 0 2 1 2 4

0 0 1 0 1 1 0 0 0 1 2 0 0 0

Caregiver

Calls e-mail 2

5

2

0

6 3 1 4 1 2 3 5 2 4 7 0 6

2 3 1 2 6 6 0 9 5 1 3 2 6

These figures provide a total of 89 calls from users (41+48), 7 non-scheduled visits to users’ homes and 51 support e-mails from caregivers.

Of the 41 calls coming directly from the elderly persons, this is the distribution of reasons for the calls:

ICT PSP Apollon

51

Final Version

Apollon – Deliverable 2.4 • • •

24 were related to privacy concerns and (renewed) doubts about what data the system is gathering.

11 calls were made to report sensor falls. This is more than the total number of visits for sensor falls (five).

6 calls were related to the working of the system itself or users reporting their own behaviour (“I just came back from doing some errands, did my daughter see that?” “Could I have access to the system? I would like to monitor the cleaning lady” “I just went to the kitchen but didn’t eat anything, please tell my niece I’m following the doctor’s diet”).

Of the 48 calls from caregivers (family members), the distribution is: •

• • •

27 calls were user-support questions about using the website, configuration options, etc.

16 calls were about interpretation of the reported activity in the website. Usually misdetections in the sensors (i.e. reporting 5 hours in the bathroom or the kitchen at night).

2 calls were related to sensor falls.

3 calls were about the user who decided to leave the pilot early.

Of the 7 non-scheduled visits, 5 were due to sensor falls, 1 due to a user leaving the pilot early and 1 due to a problem with the SIM card installed in the home gateway.

Regarding e-mail communication with the caregivers, of the 51 e-mails received: • • •

•

18 messages were questions about using the system 25 messages were about reported activity 2 messages were reports of service malfunction (no activity showed in the website) 6 messages were about e-mail alerts and SMS messages.

For the three pilot waves, the following graphic shows the total communications sent through the system (i.e. it does not include direct user initiated communications with IAVANTE, only warnings and messages sent by the system to the caregivers:

ICT PSP Apollon

52

Final Version

Apollon – Deliverable 2.4

Figure 20 Totals for the 15 users are 261 SMS messages and 252 e-mail messages.

Feedback Questionnaire The questionnaire for caregivers, as mentioned previously, has 3 main blocks: Demographics; Problems and Needs; Features. The following section provides the responses given by the main caregivers involved in the pilots. There’s only one questionnaire per elderly person, regardless of the total number of caregivers participating in the pilot.

Demographics/current situation

1.1 What is your relationship with the care-dependent person?

1.2 Does this person live independently?

1.3 Age of the care-dependent person

1.4 How many times a week do you use a computer with internet connection?

1.5 Do you have a mobile phone?

1.6 Do you have professional assistance?

1.7 Do you receive an allowance? (Users who report yes are referring to an allowance received by the elderly person for the purpose of getting help).

User ID 1.1 1.2

ICT PSP Apollon

1.1

Son in law Daughter

1.2 1.3 1.4 1.5

1.6

1.7

Yes

No

Yes

Yes

53

74 77

>5 >5

Yes Yes

No

No

Final Version

Apollon – Deliverable 2.4 1.3

Son

Yes

71

<5

Yes

No

No

1.5

Daughter

Yes

70

>5

Yes

No

No

2.2

Daughter

Yes Yes

No

1.4

Niece

2.1

Daughter

2.3

Son

2.4

Daughter

3.1

Son

2.5

Nephew

3.2

Daughter

3.3

Daughter

3.4

Yes Yes Yes Yes Yes Yes Yes Yes Yes

Daughter in law Yes

3.5

Niece

Yes

79 72 72 69 76 81 80 70 74 75 71

>5 >5 >5 >5 <5 >5 >5 <5 >5 >5 >5

Yes Yes Yes Yes

No

Yes

No

Yes

No

Yes

No

No No

Yes Yes

Yes Yes Yes Yes

No

No

Yes Yes

No

Yes Yes

No No

No No

Problems / needs 2.1 How much time do you spend per week on caregiving? (0-2 hours / 2-5 hours / 5-15 hours / 15-30 hours / > 30 hours) 2.2 How do you feel about the time spend on caregiving activities? From “totally dislike it” (1) to “totally like it” (4).

2.3 Do you feel that you have enough time available to provide good care?

2.3a How many times a week do you commute to provide care? (1-3, 3-5, 5-7 more than 7)

2.3b How long is your commute to the house of the person you care for? (minutes) 2.4 How worried are you about the person you’re caring for? (1 to 4)

2.5 What are your main concerns? (Multiple choice 1: accidents/illness 2: Food intake/hydration 3: Medication intake 4: Security 5: Loneliness/social contact User ID 1.1

ICT PSP Apollon

2.1

2-5

2.2 2.3 2.3a 2.3b 2.4 2

Yes

1-3

54

<15

2

2.5 2,5 Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 1.2

2-5

3

No

5-7

<30

3

2,3,4

1.4

5-15

4

No

5-7

<15

4

1,3,4,5

2.1

2-5

1

2,3

1

4,5

1.3 1.5 2.2 2.3

2-5 2-5 2-5 2-5

2.4

5-15

3.1

5-15

2.5 3.2

5-15 2-5

3.3

5-15

3.5

2-5

3.4

2-5

3

No

1

Yes

2

Yes

2 3 3 3 2

Yes Yes No No No

1

Yes

4

No

3 4

Yes No

1-3 1-3 5-7 3-5 1-3 5-7 5-7 5-7 5-7 5-7 3-5 1-3

<15 <15 <30 <30 <45 <15 <15 <15 <15 <30 <30 <15

2 1 1 3

4,5 3

3,4 1,2,3

4

1,2,3,5

2

3,4

4 2 3 1

1,2,4,5 1,4

2,3,5 3,4

Features / price 3.1 Which assistive products does the care-dependent person already use?

1 2 3 4 5 6 7 8 9 10 11 12

Glasses Hearing aid Cane Walker Seniorâ&#x20AC;&#x2122;s telephone (big keys) Stand up chair Raised toilet Scooter Stair lift Alarm button / pendant (home) GPS wandering detection / emergency button Screen to screen (video calls)

1 2 3

Call button (falls or accidents) Restless sleep Reduction of daily exercise

3.2 What issues related to the care-dependent person would you would like to be alerted about via or SMS or computer messages?

ICT PSP Apollon

55

Final Version

Apollon – Deliverable 2.4 4 5 6 7 8

Skipping meals Inactivity in unexpected places Fire and gas detection Night wandering Inadequate hygiene /hydration

3.3 Does using this system reduce your task load as an informal caregiver?

3.4 Does using the system give you peace of mind?

3.5 Does using the system reduce the number of visits you pay to the caredependent person?

3.6 Do you think the system will allow a care-dependent person to live independently for a longer time than would be the case without it?

3.7 Would you be willing to pay for such a system?

3.8 If you are interested in such a system and the costs are €30/month with a onetime purchase price of €250, would you, with other relatives, be willing to pay this price?

User ID

3.1

1.2

1,2,10

1.4

1,3,10

n/a

2.1

10

4,7,8

1.1 1.3 1.5 2.2 2.3 2.4

3.2

3.3

3.4

3.5

3.6

3.7

3.8

4,5,6

Y

Y

Y

Y

Y

N

1

4,5,6

1

1,3

10

6,8

5,6,7

N

Y

Y

Y

Y

Y

3.5

1

ICT PSP Apollon

Y

Y

Y

N

Y

Y

6,7

Y

Y

1

4,8

Y

Y

1,10 10

N

N

3.3 3.4

N

N

N

5,7

Y

Y

Y

1,3,4,8

3.2

Y

Y

N

n/a n/a n/a n/a n/a n/a

1,10

3.1

1,3,4

N

Y

N

1,10

Y

N

1,4

2.5

1

2,6

Y

Y

Y

Y

N

Y

Y

Y

N

Y

Y

N 56

N

Y

N Y

Y

Y

N

N

Y

Y

N

Y

Y

Y Y

Y Y

Y Y

Y

N

N

Y

Y

Y

Y Y Y

Y

N Y

N N N Final Version

Apollon – Deliverable 2.4 Focus groups As mentioned in the pilot description, for each of the three waves of users the IAVANTE team held two meetings with the main caregivers involved in the pilot of Innoviting’s ADL system. The first meeting was held approximately four weeks after the users had begun using the service and the second one once the whole eight-week period had passed.

Both sessions (times three) had a very open structure were the users themselves took the lead in the discussions.

The first meeting was centred on basic proficiency questions and the ease (or lack thereof) of using the website and the communication options for the alerts and warnings. The seed was a question about how they were coping with the system and if they already managed to understand the different sections of the website.

The second meeting focused on the users’ experiences with the service and their view of the added value that it provides for their needs in caring for a dependent relative. The seed was a question about the main advantages that the system provides for the caregiver.

In general terms, the three groups conveyed similar impressions both in the system usability meeting and in the experiences/added value meeting.

Consequently, input from the three waves of users is merged in this section.

On usability of the service

Most users reported finding the website difficult to use and understand during the first 7-10 days of use. Users had all received a demonstration/training session on the use of the platform before the pilot phase, but they still found some of the options confusing.

As we will further discuss in the lessons learned section, we believe most of these problems are related to expectations management. Most users thought of the platform in terms of the potential uses it may bring about further along its development more than in terms of what the system can provide in its current status.

In any case, users reported finding themselves much more comfortable using the service once this initial period had passed.

There were complains (frequently also conveyed via e-mail) about the verbosity of some alerts. In some cases, such as the elderly person pushing the “call button” the caregiver receives 4 SMS messages for a single push of the button.

Caregivers also reported having problems in coming out with adequate configurations for the different inactivity period to trigger alerts for the different uses.

Another point of usability friction was the “conclusions” section of the website.

This is a panel that lists conceptualized inferences that the system makes from the behavior patterns of the user. The main element in the website is a time table that provides raw information about sensors activation and a primary inference ICT PSP Apollon

57

Final Version

Apollon – Deliverable 2.4 extracted from these activations about what room the user is in at any given time. The conclusions panel seeks to further abstract the raw information into specific daily activities such as “night sleep” or “user took a shower” or “person used the toilet” based on the time of the day and the duration of the presence in the specific rooms.

The main problem with this tool is that there’s not enough granularity in the data available or enough specific adaptability to the structure of the home and sensor placement for these inferences to have a high probability of being correct.

Another added problem is that the same panel is also used for reporting problems with the sensors and gateway (loss of signal from a sensor, communications problem with the gateway, etc.). Ideally, users insisted, the conclusions panel should read like a journal of the user activity only, with reports about system problems registered elsewhere.

These impressions were shared with Innoviting experience in the Netherlands and this functionality was removed for the second and third waves, greatly reducing user confusion.

By four weeks of usage most users had learned to discard unrealistic patterns that are due to sensor misdetection, but many remarked that if they get used to discarding strange patterns that happen frequently they may also skip over a real positive. Most agreed that they would like more robust sensing. This would require bigger customization (in terms of number of sensors and their ranges/angles). Users conveyed that the system should cover all rooms in the house. We essentially concur with this impression. Having constant detection would greatly improve the inferences the system can make about user behaviour and reduce the number of errors.

Notwithstanding the aforementioned issues, users were broadly satisfied with the system and overwhelmingly reported finding it useful and a good complement to their physical presence in the elderly person home.

On experiences and value added

Once each of the whole pilot waves had taken place and the system removed from the user home, the caregivers were invited for a second meeting. These meetings were devoted to gathering input from the users in terms of their perceptions about the value added by the ADL system, how (if at all) it impacted their caregiving activities and schedule and their eventual interest in using this same technology if it was available on a commercial basis.

Rather predictably, caregivers manifested a more nuanced understanding of how the system works than during the first meetings that took place mid-pilot.

Several users reported that they would like an option to be able to cancel bad inferences to avoid polluting the data that is shown in the long term trends section of the website (for example, a misdetection at night that erroneously reports the user as having spent half the night in the bathroom will impact the “sleep hours” average shown on the long term trends section).

Users saw great potential in this type of solution and were very much looking forward to the evolution of the ADL system.

ICT PSP Apollon

58

Final Version

Apollon – Deliverable 2.4 Most insisted on the need to make detection more robust. One user said “The system is really, really useful to me, but I feel like I can trust it enough to space my visits. During the first days, I called my aunt several times when the graph (erroneously) reported she had been at the bathroom for too long or spend too much time outdoors. After a few weeks I stopped bothering her with the calls, but I couldn’t help but worry if it was a real problem this time!”

One of the users reported that his father (the cared-for person) wanted to use the website himself to check if the cleaning lady spends the expected time working in his house (this user also called IAVANTE directly to ask for that same thing).

Several users said they would like this technology merged with the available emergency button service that their elderly relatives have at home so that someone else (available 24/7) could check on the behaviour patterns and potential problems reported by the system.

Asked specifically about their preferences for the alerts (which ones to receive

by SMS and which ones to receive) it was found that there’s some (expected) correlation between computer proficiency of the users and their preference towards e-mail messages.

Also the older the cared-for person is, the more likely the caregiver is to choose SMS alerts, which are perceived by most users as more immediate (if also more intrusive with their lives outside of the caring activities).

A very common concern that the caregivers conveyed from the elderly persons was their fear of privacy loss. The IAV team corroborates that in direct communication from the elderly users this was their biggest issue with the system. Elderly users had to be frequently reassured on what the system does and does not register. Most caregivers reported that it was a very common conversation topic with their relatives during their visits and that it was brought up anytime they asked their relatives about how were they coping with the sensors at home.

Improvement suggestions from the users

A total of six users said they “would love” to have the service integrated with Facebook so that they would see all activity and messages reported in their news feeds. One of them mentioned that it would also be a great way of virally marketing the service to other potentially interested users.

Three users suggested upgrading the sensors to those that include a webcam in addition to the PIR sensor (common in modern home security systems) so that they could have a look when the system reports something unexpected (strange, dangerous or unexpected patterns, alerts…).

Two users suggested including environment monitoring with the system (temperature, air drafts, noise) because this comfort-impacting parameters are a frequent concern for them.

One user suggested updating the “call button” to become a simplified “Skype phone” that the elderly person could use to contact the caregiver directly.

ICT PSP Apollon

59

Final Version

Apollon – Deliverable 2.4 Two caregivers suggested including an option, to be controlled by the elderly user, which allows for signalling to the system that the user has people visiting them. This would avoid wrong inferences when there are several persons in the house instead of the expected single one. One of these caregivers mentioned that his relative suggested an “I want privacy now, stop monitoring me” option available in the system. She would refuse to have a service like this installed long term at her home if this option was not present.

3.6 Lessons learned on the pilot level The biggest concern of family and elderly was the reliability. What if an alarm does not get sends what if the modem breaks down, and so on. After explain the fail saves that are built in the system the users are convinced of the reliability.

We learned that this will always be something you have to repeat over and over again that INNOVITING only uses equipment when it is fully reliable.

In the intake conversations we noticed that the ADL system is directly compared to an alarm system. Even after explaining the difference and using the ADL system in real life, 50% still compare it with an alarm system. This is not directly a bad thing but we need to take this though process of the users into account.

There are two types of users and they are about 50/50. One uses the system as an alarm system, they wait for an text message and then call the elderly, a neighbour or visit them directly. The other user uses the web interface 3-5 time a day. They check in the morning if there mom or dad has gone out of bed, been in the kitchen and left for the day-care. All users check different things that are important in the parent’s behaviour. But they check it a few times a day. The checking is mainly a build-up of concerns, they are wandering if everything is well a few times and then they check the ADL system.

Also for this “web interface” type of user the beginning is quite hard. They get an information overload and a real picture of the parent behaviour. This was for all the children a hard reality, but they are always glad to know what the reality is.

They rather have a truthful view that a happy fake view. And after a few day of adjusting themselves and the parent the grip on the situation is back. We learned that the usage asks a change of behaviour from the caregivers as from the elderly.

Added to this point of where the ADL systems gives a real insight of what is going on. This could also mean that elderly should leave their house earlier or even directly. This has not been the case in the Dutch pilots but the ADL systems got the conversation of moving the elderly started. This happens in the beginning period of the usage where the realization of how good or bad the quality of life really is. This action is not supporting our goal of getting elderly to living longer at home but it is supporting the quality of life for the elderly. For this difficult question there is a double moral.

The interesting difference between the “alarm” users and the “web interface” users is that the “alarm” users have parents with only a physical disability. The “web interface” parents have also a mental disability. A bit harder to underpin is ICT PSP Apollon

60

Final Version

Apollon – Deliverable 2.4 that we noticed that the children that uses the “web interface” are more interested in technology. They had a smart phone or iPad that they used to check the application. They also could explain the technology behind the system better than the “alarm” users. We learned that the best group of users is elderly with dementia and a child who is interested in technology.

For both type of users it feels as a large responsibility for the caregiver when alarms are in their hands. They have the feeling that if they do not respond in a short time that it is their fault that something has happened to the parent. All the family suggested that it would be nice if the formal care could take care of the alarms. This would give them more piece of mind.

During the pilot there have also been more than 25 interviews with stakeholders in the healthcare ecosystem. We asked them their opinion about the ADL system and were they see a useful proposition. The interviews were with government officials, insurance companies, home care organizations, collective interest parties, consultants and suppliers. The result is that the Dutch healthcare market is financially fragmented and that different parties have different goals. All these islands see that in the future they need to work closer together but for now there is no financial backup to do this. For example; if an insurance company pays for prevention of escalations of diseases the government takes the benefits because they pay for the long term diseases. This teaches us that working within this large force field of rules and habits you got to have deep pockets and a long breath.

The option to let consumers pay for the ADL system is also a hard one.

Consumers do not buy or do much on prevention. In the evaluations the family said that are happy to pay for the ADL system, if the situation is really bad. This mainly means a parent have to fall or a doctor tells them it is no longer safe to let the elderly live at home alone. In these cases the period of usage is very short and therefore not feasible as a business case. The only way to make this option work is to make the price higher (around 2000 euro) than the maximum price than the evaluation response of 1000 euro. In the Netherlands people are used to it that the health care system is not directly charged to the customer so every euro paid feels unusual. But with all the changes in the healthcare system where consumers are forced to pay more for them, we believe that in the future this option is feasible. For the next 2-3 years consumers still need to adapt to the concept of paying for healthcare.

Requirements, common approach

In the Dutch-Spanish experiment both processes (“requirements definition” and “common approach” were executed following the process written down in Deliverable 2.1. IAV is mostly satisfied with how this process went.

Due to this, during the pilot stage, running the service locally was straightforward and for the most part free of unexpected problems that needed escalation or support requests to the transferring partners (INN and AIM).

In our view, it is essential for these activities to drill down as much as possible, despite being such an early stage within the whole project, in these areas: •

Research goals of all parties

ICT PSP Apollon

61

Final Version

Apollon – Deliverable 2.4 • •

Organizational roles foreseen to be required (this applies both at the intraorganization level and the ecosystem of participating entities or partners as well).

Clear designation of responsibilities and basic workflows among participants.

We think iterating and doing dummy testing of the aforementioned workflows would help refining the definitions early on. The use of “user stories”, to borrow a term from agile software development methodologies, would be of significant help in structuring the common approach and requirement definitions.

Partner engagement at the local level

We contemplate our own capabilities for engaging relevant members of the innovation ecosystem as a process of continuous improvement. But in this particular case there was, in our opinion, an overriding circumstance: the current financial situation.

All the SME’s that are members of Living Lab Salud Andalucía and involved in related activities to those addressed by this pilot were invited to a meeting that provided details on the aims of the project, its potential and areas of possible involvement for them. This meeting took place during the drafting period of the proposal that became the APOLLON project.

We also ran contacts with those SME’s again once the project was already a formally funded reality.

In both instances, financial concerns were the main reason for their not participating in any capabilities. In the initial effort to get partners on board (SMEs) IAV encountered great interest in the project and its approach to assist the cross-border transfer of innovative services but the SMEs found it non-viable to participate at the local level because of severe constraints in available funds for what, to them, was essentially a proof of concept effort.

This is, the SMEs found the process and approach very interesting but did not view the specific case at hand as an effort likely to succeed on a commercial basis right after the project.

In addition to that (this is our take only, not a point they have explicitly stated), the ecosystem conditions, already discussed at large within the project, didn’t seem very conducive of future business potential in this particular field for them in our region.

Fortunately, IAV assessed the expected requirements, skills and capabilities that the project would demand and the conclusion of that analysis was that the needs at this side of the experiment could be confidently dealt with by IAV with the help of FASS as a consulting partner. None of the essential activities that had to be carried away fell outside our main circles of competence.

Transfer, testing and set-up

Again, from IAV’s point of view, the key to the transfer process is a good characterization of the services, technologies and goals of all involved partners.

ICT PSP Apollon

62

Final Version

Apollon – Deliverable 2.4 The evolutionary-adaptive approach that was followed in this experiment has proved to be an effective way of dealing with (initial) high levels of uncertainty and broad (but generic) knowledge.

Detailed structured planning is not well suited for these high uncertainty endeavors, because the amount of unexpected issues that surface as the process advances frequently voids initial assumptions and estimates.

These are principles coming from agile software development methodologies that we find are appropriate for other (non-software) project environments that share the essential feature of a “weak” specification and a high probability of emerging changes along the process.

It’s important to highlight the difference between drilling down to learn and characterize as many details as possible and attempting to plan every small detail early on in the process.

Another important lesson is that when it comes with technology-based services, nothing beats hands-on time to become familiar with them. In our view this has been an absolutely essential part of the transfer. No matter how good the requirements and initial definitions are, having to set up, use and manage the technology provides invaluable insights and familiarity with it.

We attribute to this testing stage, as well as to Innoviting’s thorough documentation and cooperative attitude, the ease with which the pilot stage went from a technical point of view. Only at the early stage of deployment did we have to escalate one technical issue back to Innoviting. All the rest, we’ve been able to solve locally.

Deployments were straightforward and without technical hassles related to the Innoviting system. Innoviting provided a detailed installation document with instructions, configuration parameters and troubleshooting guides. We had experience in setting up our validation unit in Granada.

User engagement

As has already been stated IAV counted with the help of a consulting partner for this purpose with deep experience in engaging the exact kind of users that were sought for this pilot.

In light of the experiences accumulated during this pilot, there are some interesting aspects that should be taken into account when dealing with projects that look to introduce technology-intensive services to elderly people. We think these principles are for the most part general not region-specific.

•

•

Privacy concerns are extremely important for this target group. No matter how detailed and easy-to-understand is the initial documentation or presentation of the service, you should plan for continued reassurance and addressing of these concerns. It can be a huge barrier for the embracing or adoption of the services.

Schedules have to be fast: attrition augments enormously if there are significant lag times between first contacting potential users for their interest in joining the pilot and the point where actual deployment takes place. This means that user search needs two distinct stages:

ICT PSP Apollon

63

Final Version

Apollon – Deliverable 2.4 Group search: identification of relevant user sources from where to draw potential participants. This can (and should) be done early in the process. o Individual search: this is, the specific engagement of people one by one to invite them to participate. This should be delayed to as close to deployment as possible (keeping in mind that there has to be enough for scheduling the visits and providing the user with the necessary information, informed consents and the like). Two weeks is better than a month.

Provide easy means of communication for the users during the pilots and assure promptly resolution times for any issues or concerns reported. It is essential that users don’t feel that active engagement ends once they’ve joined the pilot.

Contact with users has to be fluid and permanent during the pilot duration. They shouldn’t feel unattended between joining and specific feedback gathering activities. o

•

Deployment, piloting and gathering feedback

This is another area where testing and training prevent a lot of problems in the field. In the Dutch-Spanish experiment, all systems were preconfigured in IAV facilities before installation in the field. Installations take between 30 and 50 minutes, depending on the specifics of the user’s home and the ideal points for sensor installation.

Installation is always done with two persons from our team present. Installation requires, in additional to the rather straightforward technical tasks, a lot of reassurances and explanations to the user. It doesn’t matter how detailed and simple the information in the consent document is, they always have doubts and fears about privacy and safety.

This recommendation bears repeating: all visits to a user home must always include a person that is able to explain any specific detail about the pilot, the project, the goals, the research being done, the data being collected, its future uses, the people involved and any other specifics.

For formal feedback gathering processes (interviews, meetings, questionnaire forms, etc.), the main takeaway lesson from running this pilot is that the key is to have a good mix for structured and non-structured methods. In this case the structured tool was a questionnaire agreed-upon with the transferring partners and the non-structured tool were a set of focus group meetings with the caregivers (two in each wave of the pilot, as discussed earlier in the document).

It has been our experience that for new use discovery and potential improvements to the services that arise from the users’ experience with the product, non-structured approaches work much better than specific questionnaires or interviews. Non-structured tools should ideally include a collaborative dimension (i.e. group meetings with open discussions).

Managing user expectations

An initial expectation on what a product or service does can have a huge impact on the users’ perception once they begin actually using and experiencing it.

ICT PSP Apollon

64

Final Version

Apollon – Deliverable 2.4 “Technology is never as ready to go as we engineers think it is”.

A proper assessment of the actual capabilities of the technology is achieved through the technical and usability testing processes.

In this particular case, there have been some misconceptions due to the fact that the technology at stake is an evolving one. It is only natural that the technology developer is interested in testing the very latest version of the technology, even if it is not yet completely mature.

On the other hand, from the point of view of realistic expectations it may make sense to do a more firm feature freeze and test a well characterized and polished (previous) version.

We don’t think these trade-offs can be very much abstractly formalized beforehand. It’s one of the many issues that should be evaluated on a case-bycase basis.

Furthermore, elements about potential features of the service in the future or those already available but in a limited, experimental, fashion should be addressed in the de-briefing discussions with users after they’ve tested the system in its current form. This way, there’s less confusion about the system’s real (current) capabilities and they’re better prepared to understand the new features (because they are already aware of possible current limitations in the service or they themselves have begun thinking about possible additional uses or features).

3.7 Tools and Methods deployed in the pilots

In-house testing One of the main lessons learned from running the experiments of Work Package 2 is the importance of thorough testing of the services during the transfer stage and before any actual piloting activity or.

As has been discussed before, these cross-border transfers almost always entail high uncertainty in a number of areas. Detailed testing in the local (i.e. receiving) environment is the most effective way of reducing much of the uncertainty about a service features, usability, reliability, and determining its ability to be integrated with complementary technologies or hooked up with local tools and providers.

Reducing that uncertainty is not only important for running smooth pilots with the users but also for adequate management of expectations with the local partners (avoiding the dreaded problem of “over-promising and underdelivering”).

To achieve this goal, the recommendation is to follow a structured approach to testing.

The main driver of the testing activities should be a realistic scenario. What you test is the product or service for its intended use under as realistic conditions as possible. This is, the main area from which all others (usability, accessibility, compatibility issues…) emanate is functional testing.

ICT PSP Apollon

65

Final Version

Apollon – Deliverable 2.4 Functional testing encompasses checking that all the intended features of the product work as specified. Ideally, this activity begins with a proper specification of the product or service. The higher level the better.

A particularly useful approach for functional testing is the use of “user stories”.

There’s a user story for each of the functionalities of the service. A user story is a natural language description of what a user wants to achieve when using a particular function of the service. For example “As a user, I want to be alerted at my mobile phone if my relative has been unexpectedly inactive for a long period at home”.

Each of the user stories will have a unit test. This is, a specific action that assesses if the system is able to perform the whole user story as intended.

From this initially functional testing a lot of specific issues are identified at many levels (usability problems, browser compatibility problems, technology problems, bad specifications…).

It is important to remark that the aim of the tests is always functional. Specific topics will, naturally, organize the information obtained, but that does not mean that the tests are defined based on those topics. For example, unit testing a specific user story will provide bits of information that will be reported under usability issues, other bits that are related to connectivity requirements and other elements that contribute to a report on, say, reliability issues.

Functional testing based on user stories helps greatly in getting a team that is not the original developer of the product to become familiar with it and its detailed features. It’s easier to transfer user stories without misunderstandings than lower level specifications.

One additional important reason for unit testing based on user stories is coverage. If the stack of user stories covers the whole expected functionality of the product, unit testing each user story has a high chance of finding all problems that would reach a user if they went undetected.

It bears highlighting that these functional testing activities have to be interpreted in a very broad sense to make sure coverage is complete. There will be, for example, “user” (an installer is a type of product user) stories that are about installing and configuring the product. This allows for practicing at the local level and detecting possible problems with the documentation provided or the set-up functions of the product.

ICT PSP Apollon

66

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

4. Pilots of wp2: the Dutch-Belgian Pilot The following section chronologically described the activities that have taken place within the Brussels experiment in WP2 devoted to the transfer of the Logica â&#x20AC;&#x153;Guardian Angelâ&#x20AC;? technology to Brussels for piloting with the relevant users. This experiment was not originally envisaged in the Apollon project but came along as an opportunity due to the collaboration of the partners within the work package, the willingness of the partners and the identified needs with external parties. It also was a way to evaluate the tools and methods developed and used within Apollon (both from WP1 as within WP2 itself).

Figure 21 The 'Apollon I Can Help' service being transferred to Belgium (photo taken from the kickoff session)

4.1 Description of the experiment The experiment has the same general objective and set-up as the other two experiments in WP2. A company, Logica, has developed and piloted a social emergency service in their local market, but want to transfer this to a new market. This is being facilitated by the local Living Lab that searched for the appropriate partners and establishing of the eco-system.

4.1.2 About the technology

The idea for the Guardian Angel was developed in 2004, after a conversation between a disabled person and the Dutch Red Cross. The Guardian Angel service is a paid service aimed at utilizing mobile communication technology and a wide network of volunteers to link people with a direct need for some small but acute need for assistance and people nearby who are able to provide this assistance.

ICT PSP Apollon

67

Final Version

Apollon – Deliverable 2.4 A group of people who is limited in their abilities, often due to old age or a handicap is provided with specifically designed mobile alarm equipment (GSM, GPS and GPRS) that enables them to send requests for help. At an activation of the alarm the equipment makes contact with the an emergency helpdesk. Social Emergency aid is provided by volunteers who together form a network (10,000 volunteers). For the development Achmea and Logica are collaborating in the Dutch pilot of the project.

The Guardian Angel is an alarm service, which links people in need while they are outside with a volunteer able to provide help the service has arrangements concerning personal data, location and possible medical data.

Logica, a large multinational IT solutions provider developed the Guardian Angel service for the Dutch insurance company Achmea. The service is designed and developed in close collaboration with the Dutch Red Cross. Later on this service will be adjusted to other countries needs by other partners.

One of the first instalments of the Guardian Angel project is the “Apollon I Can Help” application as piloted in the Netherlands. The underlying idea behind this application is that emergency services can be stretched from time to time. As lots of people have first aid experience or have a medical/healthcare related background, they could help in case of an emergency. The ‘I can help application’ can be downloaded as an app on the smartphone of the voluntary helpers. These helpers have to register their level of experience. They also need a BIG registration. Concretely, this means that all healthcare professionals in the Netherlands have to be registered in the BIG-register on behalf of the Ministry of Health, Welfare and Sport. This register provides clarity and certainty regarding the care provider’s qualifications and entitlements to practice.

When someone has an accident they, or someone on their behalf, will call the emergency services. The call handler/dispatcher will then be able to see where the accident is, how many registered ‘helpers’ are within a certain radius around the accident, and what type of incident they are capable of handling. Therefore, the voluntary helpers had to register their level of experience.

The dispatcher will then be able to send an alert to the appropriate ‘helpers’. A ‘someone needs help’ message will appear on the smartphone, asking if the voluntary helper can help. Using the navigational functionalities of the smartphone, a map shows the quickest route to the emergency. It will also provide the location of the nearest emergency equipment around the city, for example defibrillator and oxygen. The helper can respond to the call center/dispatcher with a ‘I can help’ message.

4.1.3 Objectives of the pilot Within the Apollon project the objectives for the pilot are situated on two different levels. First on the level of the technology, the pilot wants to: •

•

Fine-tune the Apollon I Can Help service with the input from the real client Achmea, RAVU, Red Cross, as well as possible clients in other countries, such as Johnson&Johnson Identify target groups and partners for using the service

ICT PSP Apollon

68

Final Version

Apollon – Deliverable 2.4 • • •

•

Prepare a business case for the potential clients, based on the experiences of a small-scale pilot within a real user environment Assess the impact of the I Can Help service Validate the specifics of the different countries. Allowing Logica to determine and validate what is needed to shape the Apollon I Can Help Service in the specific countries and how to organize the local and cross-border business ecosystems and involvement of the volunteers network.

Improve the early release technology which is the key for the Apollon I can help service as well as the service Apollon I can help itself by learning from the experience

The cross-border element of Apollon allows validation of the specifics for different countries. It will help the developers of the product/service to determine and validate what is needed to shape the Guardian Angel Service in different countries and how to organize the local business ecosystems and involvement of the volunteers networks, e.g. local Red Cross.

4.1.4 Set-up In order to do so, two pilots have been defined: one in the Netherlands and one in Belgium. Below we describe both set-ups.

ICT PSP Apollon

69

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

Figure 22 screenshots of the application

4.1.4.1

Set-up in the Netherlands

Before the Apollon project Logica had the Guardian Angel (GA) service for which there were very good sales opportunities with health insurance company Achmea and others.

Later on the main contacts in Achmea changed, which created delays in eventual agreement. At the same time the market also changed and Logica adapted the services to the current market and other potential client needs. Therefore the service I Can Help was created, one of the services which is inspired by GA. The Dutch pilot Apollon I Can Help (renamed) was planned to be tested together with Achmea.

ICT PSP Apollon

70

Final Version

Apollon – Deliverable 2.4

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

•Presentation of the technology to be transferred •Analysis of the Ecosystem •Assesment of potential application Figure 23 The connect phase

To implement the Apollon I Can Help pilot in the Netherlands Logica approached several external partners, which expressed interest, Achmea, Red Cross, RAVU, Vodafone and EuroCross. Different scenarios where worked out with them in workshops and we had a number of issues to consider and solve jointly. Some of the aspects of pilot set up, were not fully agreed with all the parties involved, and adjustments in the technical service where mandatory. Pilot set ups where made with Dutch Red Cross, RAVU and finally Logica’s own safety personnel.

Identified actors •

Identified roles/functions • • •

the call centre/dispatcher of the emergency service

•

•

•

the involved experienced first aid volunteers with BIG-registration

• •

respond to the emergency calls assess where the accident took place identify the registered helpers in a radius around the accident send an alert (someone needs help message) to the appropriate helpers

if needed, respond to the call centre/dispatcher with ‘I can help’ use the navigational functionalities on the smartphone and go as soon as possible to the place of accident provide help to the person in need

Table 5 actors and roles

ICT PSP Apollon

71

Final Version

Apollon – Deliverable 2.4 Connect:

Support and Govern:

Plan and Engage:

Manage and Track:

•Search and selection of local partners •Mapping and describing the present situation •Localization of technology •Research setup and research methods •Selection and recruitmentof Users Figure 24 The plan and engage phase

In the Netherlands there were multiple clients which were interested in the I Can Help service. But for a pilot in the Apollon project, the various proposed partners where anxious to perform real live pilots as in the field of (emergency) health care there are high liability risks and hardly room for extra help/money or available time.

Nevertheless we had very useful interactions and workshops with those partners like Dutch Red Cross, RAVU (regional ambulance transport Utrecht) and Achmea. This made our service as a whole better because we could fine tune the service to customer wishes.

Identified actors •

•

•

Identified roles/functions

RAVU, Region Ambulance Transport Utrecht, Dutch Red Cross, Achmea, Logica Employees, Logica Bedrijfshulpverlening (company emergency) (BHV)

• •

the 112 call centre

•

the participating volunteers

•

ICT PSP Apollon

•

•

72

provision of the care services respond to the calls coming from people who need help (including 112 emergency calls) identifies the appropriate volunteer drivers contacts the appropriate volunteers to help people in (urgent.medical) need. respond to the call centre/dispatcher when they are contacted to drive provide transport to the person in need

Final Version

Apollon – Deliverable 2.4 •

• •

Logica Netherlands

• • • • Table 6. Ecosystem in Netherlands: actors and roles

Set-up of the required ecosystem Set-up of the experiment and research framework Requirement analysis and needs assessment User research Adaptation of the application Panel management + first line support

The original service was much altered due to several wishes from Dutch and Belgium (pilot) partners. Each version is now part of the product portfolio. The I Can Help service is now not just 1 service, but had multiple forms, for various purposes. Below an overview of the 4 main versions and what the main differences are. Except from the original 1.0 version, all other versions where tested in cross border pilots in Netherlands and Belgium.

V1.0 Original I Can Help Cloud based web interface

V1.0, inc SMS Apollon I Can Help Including SMS group sms, via webinterface

On iOS 5.0 and 5.1 (iPhone and iPads) BIG registration (are you a professional in health?)

No sms functionality Push notifications Location based services Anonimity for volunteers etc. (business confidential)

With Partner CM.nl No BIG registration required

V1.11 Modified Apollon I can Help Belgium/Dutch Pilot Rename “Gebruikers” tab”

V1.2 More Modifications Change message "lifetime' (autokill)

Add platform service for storing “Overige gebruikers”-ICH Add CRUD interface for “Overige gebruikers”-service Add new tab “Overige gebruikers” Display list of users Add “Overige gebruikers” details screen, per user Add “add new user”-function Add “edit user”-function Add “delete user”-function Function for converting address to latlong (latlong is stored per user)

from 15 minutes to three days

Display “Overige gebruiker” on the map (tab “Dashboard”) Display users details on-click in a tooltip on the map Deploy the pilot environment

Table 7 modifications to the system

The research set-up within the Dutch pilot was set across Logica’s R&D. How could we pilot the I Can Help service in a way that future (cross border) roll out is optimised. Of ICT PSP Apollon

73

Final Version

Apollon – Deliverable 2.4 course, we needed to get feedback from the actual users. All stakeholders had to be involved; Volunteers, People in need, People in call centres (dispatchers) and the professional medics. Technical problems were not foreseen in the way it showed finally.

Therefore, during the pilots we had two focus areas: 1. basic technical testing and 2. user experience vs the original plan to focus on user experience only.

The research has as main objectives to explore: (similar as the Belgium Pilot) o the user experience of the current situation o the user experience of the “I can help” platform on iPhone and iPad o the contextual differences between the local and remote living lab o the remote ecosystem and business opportunities for Logica Research goal

Measured via

Responsible party

The user experience of the current situation (baseline measurement)

BHV coordinator

Logica

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

d) addressing their needs

Voluntary (emergency) health a) satisfaction level b) easy of use c) practices The user experience of the ICH-platform

d) addressing their needs BHV coordinator

a) satisfaction level

Logica

b) ease of use c) practices

d) addressing their needs

Voluntary (emergency) health a) satisfaction level b) ease of use c) practices

d) addressing their needs

Logging data of the application The remote ecosystem and business opportunities for Logica

Table 8 research setup

ICT PSP Apollon

a) the ecosystem

b) amount of business potential

74

AIM

Logica

Final Version

Apollon – Deliverable 2.4

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

• Deployment of the experiment • Data Gathering • Stakeholder management • Iterative technology adaptation

Figure 25 the support and govern phase

with regards to disasters, war etc.

Apollon (Logica) and Dutch Red Cross management had a mutual workshop/brainstorm in November 2011 about the possible Apollon I Can Help pilot.

Though initial enthousiastic, Dutch Red Cross decided that because of announcement of serious cutbacks in their services (closing of several institutions, staff reduction etc) they could no longer support our non-essential local pilot, as they are focusing on worldwide aid for people in need i.e.

The Dutch RAVU (Region Ambulance Service Utrecht) is another pilot partner. They actually set up a pilot with real (!) victims who needed urgent (ambulance) help via 112.

The volunteers involved are supposed to be professional medics (doctors, nurses, dentists, etc.). Unfortunately this pilot could not start before beginning of March 2012 and therefore was too late for the Apollon deadlines to be incorporated in Apollon.

The alternative set up for a Dutch pilot (within the Apollon timeframe) is with the use of Logica employees and the BHV (Bedrijfs Hulp Verlening/ company safety personnel).

Logica conducted a series of (fake) incidents and monitored the response times, the technical performance of the application and the experiences with all people involved.

In the Netherlands Logica struggled with external partners. After pilot set ups with Achmea, Dutch Red Cross, RAVU, we finally ended with Logica’s own safety personnel.

Available volunteers on March, 16:39 2012 in Dutch local pilot

ICT PSP Apollon

75

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

Figure 26 Volunteers on March 23, 2012 at 16:39 Dutch pilot

4.1.4.2

Set-up in Belgium

In Turnhout the pilot set-up is so that the I Can Help service of Logica will be implemented in a current social service. This social service, run by the local public organisation for social welfare, facilitate the mobility of persons by offering a pool of volunteers that are willing to drive the less mobile people (this service is called the Minder Mobiele Centrale or MMC (which stands for Less Mobile Centrale) People that for example, would need to go to the hospital or want to visit their family can make use of this social service. A central operator will take these requests and dispatch it to the group of volunteers. At this moment the operator has to mail or to call the volunteers which in some occasions has some bottleneck, such as no immediate response, need to plan upfront etcâ&#x20AC;Ś The I Can Help technology, although designed for other purposes, offers a solid base to explore a new of interaction between de central operator and the group of volunteers. It will allow the social service to assess changes in their approach and process. Therefor this technology will be embedded in the current activities and process of the MMC. Parallel to their normal communication flow, they will use the I Can Help service to dispatch the request to their group of volunteers.

4.2 Timeline of the Activities, the Connect Phase Different steps took place in setting up the experiment. Initial activities that include the compilation of the network of collaborating partners for the Flanders project were initiated

ICT PSP Apollon

76

Final Version

Apollon – Deliverable 2.4

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

•Presentation of the technology to be transferred •Analysis of the Ecosystem •Assesment of potential application Figure 27 the connect phase

At the start of the first phase in M18 as initiation of the experiment a presentation of video fragments with involvement of the Dutch Red Cross was given by Logica, which showed how the application can support elderly or less mobile people in receiving help when they need help. In order to support Logica in transferring their application towards another market/country, the remote living lab (IBBT) learned more about the application and its possibilities. These videos function to illustrate the potential usage of the service used in the project. The technology to be transferred from the Dutch context, where it is developed, to the Flanders context for testing, was the I Can Help module, which consists of a central management module (online) and a dedicated app for the iPhone..

After this first demonstration of the general ideas and principals of the Guardian Angel Project Logica the local Living Lab (IBBT) did an assessment of the core technology to see whether it was feasible to implement in the local context. After this assessment it was clear that the set-up, as rolled-out in the Netherlands, could not just be replicated in Flanders due to contextual differences: • The I Can Help application was developed for emergency situations using a pool of volunteers – all with a certified medical training, registered into a central system. In Belgium no such open system does exist • The I Can Help application was initially used by one large central organisation that use it within a specific setting. In Belgium no organisation or company was offering a similar service or had plans to do so. It was too difficult, within the short timeframe, to identify such a partner that would explore with the same concept.

• The I Can Help was developed as a iPhone application, assuming that professionals would have such high end device and a data-connection. In Belgium the penetration of iPhone devices and data-subscription is very low.

Here we differ for example with the Dutch context that already has a long tradition of conditional sale (where premium, high cost devices are being sold for a very cheap price when you would take a long term subscription with a certain provider). In Belgium it was for a long time not legal to do so (only last year this was put into legislation). In addition, also the prices for mobile data connection in Belgium are much higher then eg. the Netherlands, resulting in a much lower uptake.

ICT PSP Apollon

77

Final Version

Apollon – Deliverable 2.4 Based on these insights and due to the fact that the local Living Lab IBBT identified the opportunity at the public center for social welfare. Via this Logica would be able to assess new possibilities for its services and a potential new business model.

Within the experiment in the Netherlands, the most important identified actors and roles in the ecosystem are: Identified actors •

Identified roles/functions • • •

the call center/dispatcher of the emergency service

•

•

•

the involved experienced first aid volunteers with BIG-registration

• •

Table 9. Actors and roles

respond to the emergency calls assess where the accident took place identify the registered helpers in a radius around the accident send an alert (someone needs help message) to the appropriate helpers

if needed, respond to the call center/dispatcher with ‘I can help’ use the navigational functionalities on the smartphone and go as soon as hpossible to the place of accident provide help to the person in need

An ecosystem specific element is that the volunteers need a BIG registration. Within the limited timeframe that was available, only 3 months left within the Apollon project, and taken into account that in Flanders lacks an equivalent of the BIG-registration, Logica and IBBT decided that it wasn’t feasible to transfer the ‘I Can Help’ application as such, within the context of an emergency service and with healthcare professional volunteers.

As an alternative, a different approach for the experiment was chosen based on the identification of the need of one of the partners within the IBBT Living Lab network.

This alternative provided Logica the opportunity to test and validate new functionalities on the services as well as new business models. For the local partners, they were able to assess this new technology in relation to their need for a more efficient communication with their users.

From the local ecosystem in Flanders it was clear that for the pilot two important limitations needed to be taken in account: • The call center/dispatcher should not be related to an emergency service (because this kind of partner isn’t available yet in the IBBT living lab ecosystem, and it will take too long to engage such a partner) • Users of the application/volunteers do not need first aid experience to be able to function in the pilot

Based on the possibilities of the ‘I can help’ application and the above described requirements for the remote ecosystem, a re-scope of the application was elaborated. In consultation with Logica, it was decided to adjust and extend ‘I Can Help’ application in ICT PSP Apollon

78

Final Version

Apollon – Deliverable 2.4 order to also serve as a tool in a service oriented towards the support of people in social need.

During the execution of the Apollon project AIM has interacted with Logica to set-up a cross border healthcare pilot. This was in addition to the Innoviting cross border pilot, as AIM wanted to maximize the cross border learning from healthcare living lab pilots.

The Amsterdam Living Lab, under responsibility of AIM, had started the e-health living lab and wants to maximize the learning w.r.t. the healthcare ecosystem and cross border transfers. While Logica had outlined interest in the healthcare domain the first pilot to be considered for cross-border transfer was the Message Board solution. The Message Board pilot would use the established eco-system to test and validate a new technology and service. However during the investigation of the cross border possibilities, i.e. the business case for transfer, Logica and AIM have decided to go for another technology & solution to be tested in the Apollon. Three reasons for the selection to the I Can Help pilot (based on the developed Guardian Angel concept & technology) over the initial Message Board solution:  Business wise much more attractive for Logica to investigate in a cross border setting  Better alignment with foreign living lab in the Apollon setting, i.e. Belgium setting  Technology readiness, i.e. much more mature and stable technology

During the definition of the pilot Logica and AIM have been interacting to focus the pilot set-up and provide a research framework for executing the pilot. AIM has facilitated Logica in the connection and engagement with the Belgium Living Lab and to assist in capturing the results.

4.3 Timeline of the Activities, the Plan and Engage phase The second phase of the experiment started shortly after the decision to transfer a part of the technology. In the second phase a considerable adaption of the experiments was done. To be able to run the experiments the receiving Living Lab (IBBT) started to further setting up local network of collaborating organizations.

In this phase the detailed planning for the experiment, as well as the selection of the research methodology, with the appropriate data gathering methods, was made.

ICT PSP Apollon

79

Final Version

Apollon – Deliverable 2.4 Connect:

Support and Govern:

Plan and Engage:

Manage and Track:

•Search and selection of local partners •Mapping and describing the present situation •Localization of technology •Research setup and research methods •Selection and recruitmentof Users

Figure 28 the plan and engage phase

4.3.2 The local ecosystem IBBT explored potential partners and came via the municipality of Turnhout in contact with the Social Services director of the OCMW Turnhout, (public healthcare and wellbeing organization) who was interested in the possibilities of the ‘I can help’ application. They saw the opportunity to experiment with this technology in the context of the ‘Minder Mobielen Centrale’ (MMC) service of the OCMW Turnhout. The MMC is a service of the OCMW which matches people who require transportation with volunteers who are able to give that. The plan made was to adapt the mobile application technology component of the Guardian Angel Project for use in the matching.

The local ecosystem for the service was analysed and the most important actors and roles described. Partners capable of performing the needed functions were defined and agreed to partake in the experiment.

Within the experiment in Flanders, the most important identified actors and roles in the ecosystem are:

Identified actors • •

Identified roles/functions •

OCMW Turnhout – care organization

the call centre/dispatcher of the MMC service (the service provided

• • •

ICT PSP Apollon

80

provision of the care services, and more specific in this case the MMC service respond to the calls coming from the MMC members identifies the appropriate volunteer drivers contacts the appropriate volunteer drivers until an appropriate driver is found Final Version

Apollon – Deliverable 2.4 •

•

the participating volunteer drivers

•

Remote living lab (IBBT)

• •

•

• • • •

•

Logica

•

Table 10. Ecosystem in Flanders: actors and roles

respond to the call centre/dispatcher when they are contacted to drive provide transport to the person in need Set-up of the required ecosystem Set-up of the experiment and research framework Requirement analysis and needs assessment User research Panel management + first line support Training of the MMC coordinator Adaptation of the application

service

To better understand the added functionality and the benefits of the Guardian Angel Project for all participants in the ecosystem a mapping or description of the MMC service provided by the OCMW Turnhout and the current working process was made.

The OCMW Turnhout offers via the MMC service transport to people with mobility problems. A pool of volunteer drivers (currently 15 volunteers are involved) provides the transport of the elderly or mentally handicapped people or people in a social emergency situation (e.g. people who wish to visit their family, have an appointment with the doctor or the hospital,). Members of this service who need transportation have to call at least 2 days in advance to the MMC call centre. The call centre coordinator seeks a volunteer driver who is available at the requested time and arranges for him to bring the person with mobility problems to its destination.

Currently, the working process is as follows:

 Member of the MMC service calls – at least two days before the needed transport to the MMC service coordinator and request a ride  The MMC service coordinator calls volunteer drivers until a driver is found who can provide the requested transportation at the preferred time and location.  The contact between the customer and the driver is established and the transportation is provided.

The advantages and disadvantages of the current MMC service were identified by IBBT in consultation with the OCMW Turnhout: Pro’s current situation

Cons current situation

There is a direct personal (by phone) contact between:

Time intensive process for MMC coordinator to answer the requests on the one hand; and on the other hand to call / e-mail the volunteers till a driver is found  the coordinator wants to spend less time in ‘administration’ and more in social contacts with

1) members of the MMC service and the MMC coordinator 2) the MMC coordinator and the ICT PSP Apollon

81

Final Version

Apollon – Deliverable 2.4 voluntary drivers

the voluntary drivers Members of the MMC service must call at least 2 days in advance  responding to urgent social emergencies is therefore not possible (currently, it is not the aim of the MMC service to provide ‘social emergency’ transportation services’ towards its members) During search for a voluntary driver, the distance between the user of the service and the voluntary driver is not taken into account

Table 11. Present situation MMC service in Flanders

The needs and expectations of the OCMW Turnhout with regard to the ‘I can help’ application and with regard to the experiment were identified by IBBT in consultation with the OCMW Turnhout.

Overview of the most important/crucial needs expressed during the needs assessment:

Needs/expectations with regard to the ‘I can help’ application

Needs/expectations with regard to the experiment

The application should be able to be used also by volunteers with a traditional mobile phone (and not only by volunteers with an iPhone)

The service towards the members must be provided as fluent as always (members may not feel negative consequences and the service must be guaranteed for 100%)

Mobile phone users should also be able to respond to the ‘Can you help’ message

Table 12 needs and expectations

The OCMW Turnhout wants to optimize its working process behind the scenes of the MMC service, currently the phone calls with the voluntary drivers are too time consuming, they expect that the experiment can offer some insights in the fact that social media can be used to facilitate their working process

4.3.3 Contextualisation of the technology Logica has localized its Guardian Angel technology by adapting its ‘Apollon I Can Help’ application to function so that it fulfils the demands of the OCMW Turnhout MMC service. After these adaptations, the ‘I Can Help’ application was extend by an additional, separate module. This was an SMS module through which the operator was able to also send out request to those users that haven’t an iOS device. The SMS module was accessible through a separate webinterface.

1. SMS: To include not only smartphones (iPhones) but also normal mobile phones we provided a group SMS service which can be send from a computer dashboard to all volunteers. Volunteers can respond if they can /or cannot be involved in the call for assistance. The service is running on a SMS shortcode (8850) and is hosted -via Logica- by CM.nl an international operating SMS provider.

2. iPhone application: For Apollon we use the ICH/Gov2Go solution (ICH iPhone app + ICH webportal) to do a pilot. Because users without a smartphone are also

ICT PSP Apollon

82

Final Version

Apollon – Deliverable 2.4 relevant for the pilot we use a SMS gateway to reach these users (= a totally selfcontained SMS gateway, no integration with ICH). A precondition for the pilot is a way of registration the non-smartphone users within the ICH webportal. Our client has seen the existing ICH solution and has requested the registration functionality that is needed to start the pilot. Therefore a requested registration functionality was assessed. “To add extra (non app) users at least manually into the "I can help", register their static location (eg. in details) and show these addresses on the map" This would be a necessity. The full integration of the SMS would be good, but maybe not feasible”. As a solution All adjustments are done to the ICH webportal. There still no SMS integration. We rename the existing tab “Gebruikers” to “App gebruikers” and add a new tab “Overige gebruikers” On this screen one can manually add, update or delete users (first name, last name, telephone number, street name, street number, zip code, city and country). Al registered users are displayed on the screen (last name, first name, country, ordered ascending by last name). The users details can be displayed by clicking on row details. All registered users are displayed on the ICH visual map (tab “Dashboard”), if the address is valid.

3. Tasks: Below are details about the work breakdown structure (WBDS) to do the above mentioned alterations: • Start up • Rename “Gebruikers” tab” • Add platform service for storing “Overige gebruikers”-ICH • Add CRUD interface for “Overige gebruikers”-service • Add new tab “Overige gebruikers” • Display list of users • Add “Overige gebruikers” details screen, per user • Add “add new user”-function • Add “edit user”-function • Add “delete user”-function • Function for converting address to latlong (latlong is stored per user) • Display “Overige gebruiker” on the map (tab “Dashboard”) • Display users details on-click in a tooltip on the map • System test • Rework • Deploy the pilot environment • Project coordination

ICT PSP Apollon

83

Final Version

Apollon – Deliverable 2.4

Figure 29. Screenshot of SMS message dashboard

Figure 30. Screenshot of received messages

The research set-up within the pilot followed a a user centric approach, in which we will not only focused on the deployment of the ‘I Can Help’ application in the MMC service, but also investigate on how various users experienced the service in their everyday life practise. The user research focuses on the MMC service coordinator and the

voluntary drivers.

The research has as main objectives to explore: o the user experience of the current situation o the user experience of the extended SMS module o the user experience of the “I can help” platform ICT PSP Apollon

84

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 o o Research goal

the contextual differences between the local and remote living lab the remote ecosystem and business opportunities for Logica

The user experience of the current situation (baseline measurement)

Measured via

Responsible party

MMC service coordinator

IBBT

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

d) addressing their needs

Voluntary drivers active within MMC service a) satisfaction level b) easy of use c) practices The user experience of the SMS-platform

d) addressing their needs

MMC service coordinator a) satisfaction level

IBBT

b) ease of use c) practices

d) addressing their needs

Voluntary drivers active within MMC service a) satisfaction level b) ease of use c) practices

d) addressing their needs

Logging data of the application The user experience of the ICH-platform

MMC service coordinator a) satisfaction level

IBBT

b) ease of use c) practices

d) addressing their needs

Voluntary drivers active within MMC service a) satisfaction level b) ease of use c) practices

d) addressing their needs ICT PSP Apollon

85

Final Version

Apollon – Deliverable 2.4 Logging data of the application The remote ecosystem and business opportunities for Logica

a) the ecosystem

b) amount of business potential

Table 13. Research in the Experiment

IBBT

Logica

The selection of the test-users was done in collaboration with the MMC. It was decided to involve all users that already work as a volunteer at the MMC. But also the MMC itself acted as a test user.

An in-depth profiling of these test-users is required. Such a baseline measurement is needed in order to detect impact at the end of the experiment. Through an intakequestionnaire, we were able to map the socio-demographical data, the ICT-skills and the level of involvement of the volunteer drivers into the MMC service. Also, we gained insight in their user experience with regard to the current MMC service situation, from the coordinator of the MMC service, we will learn the current practises of the MMC service and workflow.

4.4 Timeline of the activities, the Support and Govern Phase During the third phase of the experiment, which has started at M22, the actual deployment of the technology in the remote environment and the implementation of the service were realized. During the actual roll-out of the experiment various data were collected by the local Living Lab using different methods.

Connect:

Plan and Engage:

Support and Govern:

Manage and Track:

• Deployment of the experiment • Data Gathering • Stakeholder management • Iterative technology adaptation

Figure 31 the Support and Govern phase

We identified different crucial and core activities during the ‘Support and Govern’ phase:

1. Selection of the research methods and data gathering 2. Implementation of the technical infrastructure and deployment of the experiment 3. Management of the different stakeholders involved 4. Iterative technology adapation

ICT PSP Apollon

86

Final Version

Apollon – Deliverable 2.4 Each of these core activities is described below.

4.4.2 Research set-up The research methods we applied was based upon the goal and scope of the project, the specific research questions and the stakeholders involved. A combination of methods was used (online questionnaires, telephonic interviews, logging…). Through these methods we were able to get feedback from the stakeholders: the voluntary drivers, the coordinator of the MMC service, Logica.

The first two actors provided us mainly insights in the use and experience of the service as well as the impact and value. The latter two mainly commented on the implications on the technology design. In addition, via the logging we also had a good, objective overview on the various use (frequency, type of use…) of the applications itself.

The research set-up was divided into the following four phases: 



Benchmark or baseline measurement.: Before concrete implementation of the technology and the deployment of the experiment a benchmark was conducted by IBBT with both the coordinator as well as with the voluntary drivers. With the coordinator of the MMC service and the director social affairs of the OCMW Turnhout. there was an in-depth interview. The objective of this interview (that took place at 27/01) was getting insight in the current operational working process and workflow of the MMC service. During the kick-off meeting (16/02), the voluntary drivers were profiled via an intake questionnaire (see annex). The most important elements measured are:  Socio-demographical data (sex, age, family situation, etc.)  Media possession, media use, media skills (particularly mobile phone and sms skills)  Current involvement and expectations with regard to the future involvement of the volunteer in the MMC service  Attitudes towards the use of new media in the operational working process of the MMC service  Motivation of the voluntary drivers to be a volunteer in the MMC service

Continuous logging (during the experiment) During the experiment, continuously data has been gathered. This has been done via two approachtes. First, during the first 3 weeks of the experiment, the voluntary drivers were asked to complete a diary (see annex), where they can note their feedback about the experiment. The coordinator of the MMC service is continuously monitoring and logging issues based on elements they encounter of being informed by the drivers. These issues were send towards the remote living lab IBBT and also directly to Logica and CM (subcontractor). Via the applications itself, data has been logged as well. We identify event acknowledgements (acknowledge time, remark, status) and

ICT PSP Apollon

87

Final Version

Apollon – Deliverable 2.4



reported events (title, description, reported time, position, registrant, event type, acknowledge count, timestamp, tenant Id, geoposition).

Preliminary results (after 2 weeks of using the system) To gather already a first feedback on the use of the system, the IBBT living lab launched, two weeks after the start of the experiment, an online survey towards the voluntary drivers (see annex). To facilitate this we used the online tools of IBBT.

Figure 32 screenshot of questionnaire



End evaluation (after 5 weeks of using the system) At the end of the experiment – 5 weeks after deployment of the experiment – an end evaluation of the experiment has been executed. This postmeasurement will not only focus on the overall experience and use of the ‘I Can Help’ applications in the daily life of the end-users, but also looked at the impact as well as the adoption opportunities. The latter two are done at the level of the test-users and at the organizational level of the OCMW Turnhout.

For each of these phases the appropriate method was applied for each of the stakeholder involved: Voluntary drivers Baseline measurement Continuous logging

Intake questionnaire

Coordinator of the MMC service In-depth interview

Preliminary results

Online survey

Phone interview

ICT PSP Apollon

Diary

Diary

88

Applications itself

Logging data by applications itself Final Version

Apollon – Deliverable 2.4 after two weeks End evaluation after 5 weeks

Questionnaire Focus groups

In-depth interview

4.4.3 Implementation of the technical infrastructure and deployment of the experiment For the deployment phase we identified, based on the lessons learned from the previous pilots in the WP, different activities that needed to be executed in order to have the pilot up and running in the best conditions. Chronologically, the following activities have been performed.

•

• • • • •

• •

•

Identification of the processes of the MMC service at the level of the OCMW Turnhout by the local Living Lab. Especially with regard on how they contact the voluntary drivers.

Adaptation of the ‘I Can Help’ - service by Logica. This included some keychanges at the dashboard functionality (in terms of messages) as well as adding an SMS component to the system.

Live-test (19/01) of the technical applications by Logica in the remote living lab IBBT. The both applications were tested before implementation within the MMC service of the OCMW Turnhout.

Installation of the technical infrastructure within the MMC service by Logica & IBBT (16/2).

Training of the coordinator of the MMC service by Logica (16/02).

Kick-off meeting with the voluntary drivers (16/02) at the OCMW Turnhout.

During this kick-off meeting, the following topics were addressed: 1. Profiling of the voluntary drivers (baseline measurement – see further) 2. Information about the experiment, the roles and activities,..

3. Expectation management 4. In depth overview and demo on how the system can and has to be used.

This was done by means of presentation and live demo for both groups: the group that will work with the standard mobile phone I Can Help system and one group that will use the iPhone I Can Help application 5. Administrative arrangements were fulfilled (assignment of the ‘user agreement’ and ‘privacy consent’). This was important to not only guarantee the privacy of the users, but also to make sure that the application (which is still under development by Logica) is treated as confidential.

A baseline measurement was performed in which the voluntary users ware profiled as well as how they are currently operating or executing their different tasks.

After two weeks of piloting, some first feedback was gathered (by online survey – 06/03). These preliminary results were presented to both Logica (and its subcontractor) as the MMC. This was used in the iterative approach of the pilot to further adjust the service as well as the pilot in general.

At the end of the experiment an exit measurement was conducted at all stakeholders to assess the impact and identify the lessons learned.

ICT PSP Apollon

89

Final Version

Apollon – Deliverable 2.4

Figure 33. Kick-off of the 'I Can Help' pilot in Flanders with the testpanel

4.4.4 Management of the different stakeholders involved As explained in the previous phases, different stakeholders are involved within this experiment. The necessary stakeholders were identified through an ecosystem analysis which was conducted in joined collaboration by IBBT and Logica. During this exercise the necessary roles and responsibilities to conduct a pilot in Belgium was discussed and listed. The following stakeholders were involved: 





Technology-supplier: Logica as supplier was responsible for all aspects with regard to its technology, including providing the necessary technical assistance and iterative development. For the additional SMS component, CM an SME from the Netherlands was involved (through subcontracting by Logica). They were responsible for the technological support of their specific component.

Local care organization: The OCMW Turnhout, with support from the local authority City of Turnhout. They were not only, through their MMC subdivision, the user of the service but they were also responsible for the initial contact with the voluntary drivers of the MMC. Remote living lab: IBBT was responsible for the contacts with the local stakeholders, the recruitment of the test users, setting-up and conducting the research-activities. This was done in close collaboration with the local care organisation.

In order to deploy the pilot as efficient as possible, it is necessary that a central party (in this case IBBT) manage these stakeholders and support them. This is necessary to take ownership, conduct the overall coordination and to assist the stakeholders with efficient communication, collaboration and tracking tools and methods.

ICT PSP Apollon

90

Final Version

Apollon – Deliverable 2.4 In addition we also, based on previous experiences of the other pilots, performed an expectation management process towards the local stakeholders: both the MMC serce as well as to the test panel. This expectation management was not only performed before the actual trial, but was extended by providing full support to these stakeholders throughout the whole testing period. This was done through: • • •

Providing support through the IBBT/iLab.o test panel management facilities (phone support 7/7, support by e-mail, etc.); A continuous monitoring and tracking of the issues (what’s going wrong, how to resolve this, who has to take action, etc.) and dispatching them to the right partners; Communicating on a frequent base with the various partners via phone, Skype, e-mail, F2F contacts.

Via this process we were able to identify – during the pilot - various issues with regard to the iPhone I Can Help application. More in detail the following 9 issues were tracked and reported to the different partners. They were the starting point of a next process in terms of addressing them (with involvement of the partners, pre-testing, gathering more details…

Issue

Date

Who?

Towards…

Short description

1

16/02

MMC

Logica

It should be possible to send messages one by one.

2

17/02

MMC

Logica

2 test-messages were sent towards the iPhones.

Problem: they do not arrive.

1

3

16/02

17/02

Logica

MMC

MMC

Logica

3

18/02

Logica

MMC

4

20/02

MMC

Logica

2

18/02

Logica

MMC

5

20/02

MMC

Logica

6

20/02

MMC

Logica

7

20/02

ICT PSP Apollon

MMC

Logica

Currently not possible. Logica will check or this can be changed.

Log-in on the dashboard of the Apollon I Can Help platform isn’t possible anymore with provided login details/password.

New log-in details/password are sent towards the MMC. The problem was solved: administrator password hadn’t sufficient rights to send the messages.

MMC receives error message when opening the hyperlink of the dashboard of the Apollon I Can Help platform.

2 volunteers cannot read the message on their iPhone. The message displayed is: “De inhoud van dit bericht kan niet weergegeven worden”.

One volunteer cannot log-in on his iPhone.

The MMC cannot identify the volunteer who responds to a message

 important issue: MMC has to be able to identify 91

Final Version

Apollon – Deliverable 2.4

8

22/02

IBBT

Logica

8

22/02

Logica

IBBT

9

02/03

MMC

Logica

5&6

02/03

Logica

MMC

5

01/03

MMC

Logica

the volunteer who responded: this issue has to be solved for continuing the experiment

The notifications of both pilots are displayed in the Apollon I Can Help platform (both: Netherlands as Flanders). Both pilots should be separated for several reasons… (eg. privacy, clarity…).

This was due to some testing by Logica. Logica will check if they can delete the test messages.

Volunteers can hear a message on their iPhone, but they can’t read it: the message displayed says: “het bericht is onderweg”.

There is a continuous error message within the dashboard of the Apollon I Can Help platform. The MMC can log-in into the platform, but they receive error messages. MMC asks or Logica is doing updates on the platform.

The problem cannot be reproduced/identified by Logica. Possible reasons can be: •

•

•

5

02/03

IBBT

Logica

5

02/03

Logica

IBBT

9

02/03

Logica

IBBT

when the volunteer doesn’t respond within 15 minutes, the message disappears from the list when volunteers are not within the radius indicated in the dashboard of the Apollon I Can Help platform, the message will not arrive by the volunteer When there is a problem with the Cloud (which was the case last Wednesday), the message will not arrive by the volunteer  to solve this, the volunteer has to fix the connection by click on unregister/register

Is it possible to change the parameter, so the messages sent to the volunteers will not disappear after 15 minutes (this pilot is not oriented towards urgent reactions of the volunteers).

Logica will check if they can change the parameter (so the response time).

Logica had a phone call with MMC. The problem was solved via logging-out and logging-in.

Table 14 various issues with the system that were solved during the pilot

Also, with regard to the mobile phone I Can Help platform, we monitored issues. This overview can be found in the annex.

4.5 Manage and track: the outcomes of the experiment During the last phase of the cross-border experiment, the manage and track phase, the results from the experiment are analysed and disseminated to the stakeholders. They form the basis of potential new projects, new insights in the existing technology and the explored market.

ICT PSP Apollon

92

Final Version

Apollon – Deliverable 2.4

Connect:

Plan and Engage:

Support and Govern:

Manage and Track: •Analysis of Results •Dissemination of results •Potential new projects

Figure 34 the manage and track phase

4.5.2 Outcomes on the pilot level The outcomes of the “I Can Help” are situated on different levels.: • •

Results from the benchmark study: who is the testpanel, what are their current practices and experiences Results from the user experience on the use of the ‘I Can Help’ application: both on the level of the existing iPhone application as well as on the new SMS component.

4.5.2.1

Benchmarking the MMC service

The benchmarking exercise was not only useful for the preparation of the pilot, but it was also very helpful for the MMC service. They only have informal feedback of their users, but have never had the time or the resources to properly map their volunteers. Also with regard to their own activities, no objective evaluation has been performed. Although many issues are known implicitly, they have never been addressed or listed before.

With regard to the MMC service itself, it is clear that the current working process is too time-consuming for the coordinator. The OCMW Turnhout is searching for an efficient solution to make this less time intensive and more efficient and productive. But the way of doing this, the parameters and the requirements of such solution is not defined. The current organization has a strict procedure to be followed in order to deal with the workload and leaves almost no margin to handle, on a flexible way exceptions or last minute request.

The benchmark towards the test panel was based on an in-depth profiling of the users which focused on the one hand their overall profile and on the other hand at their current use, as a volunteer of the MMC service.

When looking at the profile of the test panel, the following summary can be given:.

•

Socio-demographics: 9 men (90%) and 1 woman (10%) are included in the profiling. Their average age is 60 years old. 5 persons are married, 4 persons are single, 1 person is living together with his son. The most of them have children (90%) and grandchildren (60%). 6 of the 10 persons are member of an organization (like a sports club, a hobby club, etc.).

ICT PSP Apollon

93

Final Version

Apollon – Deliverable 2.4 •

• •

Media possession: the most popular media are mobile phones (90%) and desktop computers (90%), followed by television (80%), digital television (70%), fixed phone line (70%), GPS (70%), DVD-player (70%), laptop (50%), video recorder (30%), tablet (10%), game console (10%).

Mobile phone: 7 persons have a standard mobile phone, 2 persons have a smart phone, 5 persons have a subscription and 3 persons use a pay Mobile phone skills: the voluntary drivers assess their mobile phone skills from very good (1 person), over good (5 persons) to neutral (2 persons). Also their SMS skills were measured. See figure below.

Figure 35. Overview mobile phone skills test panel

With regard to the current use and involvement of the MMC service, the following key-elements can be listed: •

• •

Involvement: 2 persons take care for more than 10 transports a week, 4 persons have an average of 4 till 6 transports a week, 2 persons do 2 till 3 transports a week and 1 person is doing less than 1 transport a week (with an average of 2 transports a month). 3 persons are mostly doing the same trajects/transportations, 1 person is always doing other transport, and 6 persons indicate that they do combinations of both (same and variable transports).

Future involvement: 2 persons are prepared to do more transports, 7 people are happy like it is, 1 person has no opinion.

Attitudes with regard to the use of new media in the workflow or working process of the MMC service: 7 persons prefer to be contacted at least 2 days before they have to do a transport, 1 person prefer to be contacted at least 1 day upfront and for 2 persons it is of no interest how long upfront they are contacted. Currently, all the involved voluntary drivers are contacted by e-mail to do a transport, 4 out of 10 receive a phone call on their mobile phone and 3 persons are contacted by their fixed phone line. Attitudes towards the use of SMS for fixing the transport dates are as follows: 1 person is very positive, 4 persons are positive, 3 persons haven’t an opinion and 1 person has a negative attitude towards the idea to be contacted by SMS. See also figure below.

ICT PSP Apollon

94

Final Version

Apollon – Deliverable 2.4

Figure 36 Attitude towards integrating SMS in the MMC service workflow

•

Motivations of the voluntary drivers to be a volunteer in the MMC service: societal involvement, helping people, contact with people, meaningful time allocation

4.5.2.2

Results of the user experience evaluation

We identify results on the level of the voluntary users (online survey) and on the level of the MMC service coordinator.

1. The dedicated iOS I Can Help application

When looking at how the voluntary drivers experienced the I Can Help application we do see that they are still confronted with a number of technological issues and lack of sufficient skills to benefit in the most optimal way of the service. We summarize some of their experiences: •

After almost 3 weeks of experiments, none of the users that has received an iPhone was able to receive a message on the iPhone yet. They received all messages from the MMC coordinator via other media.

ICT PSP Apollon

95

Final Version

Apollon – Deliverable 2.4

Figure 37 user experience results iPhone users (voluntary drivers)

Also the MMC coordinator experienced difficulties or unforeseen counter effects at the introduction of the iPhone service in their activities. The most important elements are: •

•

•

• •

It appeared that messages are deleted after 10 minutes. In contrary with the experiment in The Netherlands – where it is intended for immediate interventions. For the MMC service the context is different and it is necessary that volunteers can view their message till the day of their activity..

The I Can Help service only dispatch messages to those volunteers that are located within a certain perimeter. This message is received to all the voluntary drivers in that area. For the MMC service, it would be more useful if this would work with a cascade system. In case of a request the message is sent to a first volunteer, based on its availability and preference, and if that person is not able to respond to it, it will be distributed to the next possible candidate.

Currently the system did not allow to identify the volunteer who responded to the message with I Can Help. In the case of the MMC service, the coordinator needs to know who is responding. This for several reasons: 1) the coordinator needs to know this, so she can tell it to the clients. 2) the coordinator has to have an overview of the volunteers who are driving, so she knows who is still available.

There isn’t an overview available in the platform based on the request and the responses: who will drive, who is still available.

The current iPhone I Can Help platform is developed for emergencies and immediate response. From the start it was clear that this was less appropriate for the MMC service. But although some of the elements would perfectly fit to the service, it is clear that the I Can Help service needs to have a different architecture and set-up to fit the current needs of the MMC service.

2. The I Can Help extended component (SMS module) To (partly) meet up with the needs of the MMC service the I Can Help technology was extended by an SMS component. This component was rolled out to most participants during the pilot. As this has other processes and use, we investigated the use of this component separately.

ICT PSP Apollon

96

Final Version

Apollon – Deliverable 2.4 Looking at the results, we noticed that in the beginning we still were confronted with a number of technological issues, which we didn’t experience during our technical trials. This of course has influenced the user experience of our test panel. Only a limited set of users received one or more messages on their mobile phone. Important is that they find the message clear. This already indicates that SMS can work as an effective communication channel. From those that have received messages of the MMC coordinator, only a few persons were able to respond via the same channel. Important is also that the users still hang on to the communication patterns and methods they are familiar with. But, however this attitude, there are only 2 persons indicated that it is still necessary to receive message via these traditional media. This offers an opportunity of the MMC service to further experiment with alternative communication channels..

Figure 38 user experience results mobile phone users (voluntary drivers)

But also on the level of the MMC service they overall experience is positive, taking into account that they are still being confronted with a number of issues.

We sum some of the main issues that need to be resolved in order to have an optimal experience and effectiveness in the use: •

•

•

Usability issues: o Currently there is no general overview available in the platform. The system only provides an overview of the dates of the events. You need to click on these dates, to see what information (has the voluntary driver already answered or not) is behind.

Functionality issues o The system should be able to send automatically a message when a voluntary driver has answered on the message. This answer should be visible in a general overview. o It should be possible to note remarks into the system. For example: a volunteer driver, who is on a vacation, should not be contacted. o The system is not yet stable as certain volunteers receive messages, while others don’t or receive messages that aren’t readable.

Business issues: o An important issue is also the cost for the volunteers. Answering by email is for free, sending messages on a mobile isn’t! People involved are

ICT PSP Apollon

97

Final Version

Apollon – Deliverable 2.4 doing this also on a voluntary basis, so cost of the service is an important issue.

4.5.3 Lessons learned on the pilot level Besides the specific results of the experiment itself, this pilot also generated a number of lessons learned on the cross-border collaboration. As mentioned in the beginning, the objective of this panel was also to assess the lessons learned from the other pilots, from the APOLLON tools and methods… On that level we do see that the overall APOLLON methodology (the 4 phases: Connect, Plan and Engage, Support and Govern, Manage and Track) provides a good framework to define the different activities in a good chronological and logical way. Next, due to a good requirement analysis, a proper value analysis, we were able not only to construct the proper eco-system (by bringing the partners together), but also identify the expectations off all partners and to transfer the service in the most optimal way (taking into account the limitations in terms of time and resources.

But although these elements, we still experienced some elements within the setup of a cross-border pilot, that are important to mention: •

•

•

There is a clear need for a monitoring tool which on any time give all partners that are involved on overall overview of the status of the project. This has to include what partners are doing, what issues they are addressing as well as how the pilot is getting along. Currently now the remote Living Lab (IBBT) is being addressed to provide this info, but often ‘runs after the facts’ and doesn’t have not always the most up-dated info.

In line with the above, there is a clear added value for direct contacts between the partners involved (e.g. during the discussions for solving technical issues, there were some direct contacts between the care organisation OCMW Turnhout and CM (subcontractor Logica). In previous pilots we noticed that the Living Lab still plays too often a central, kind of gateway role, for different reasons (eg. to safeguard their own partners…). But it is important, once the eco-system has punt into place and partners are introduced to each other, that also the communication between these partners themselves. In our Pilot the various partners (even the b) communicated directly to each other (keeping the others informed) This kind of direct and clear communication was very efficient. The living lab does not always need to play the facilitator role for each element.

Although, an important lesson learned is the need for good agreements concerning this direct communication and sharing of information. On a certain moment, the living lab (and even Logica itself) weren’t informed about all issues discussed.

Early contact between the various partners – in our case SME / big company (Logica) and care organisation (OCMW Turnhout) is needed. This is important with regard to the expectations, needs,… We do see that the presences of the companies are stimulating the cross-border collaboration. This was something that we learned from the Xtramira pilot in Helsinki, where the SME was not always that visible for the other partners. The fact that Logica was present during the kick-off meeting and that they are directly reachable is a necessity for a good collaboration. It provided much more credit by the MMC coordinator and

ICT PSP Apollon

98

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

â&#x20AC;˘

resulted in a more comprehensive understanding of the experimental design of the technology (and its failures).

It is important to note that the selection of volunteers/user groups can play an important role in the pilot execution. The users should be comfortable with the technologies and devices offered them for the pilot. For instance, 65+ years old users may have difficulties with new technologies, such as iPhone (Apollon I Can Help App is made for iPhones/iPads). While for this age-group of users simple devices with four buttons (Guardian Angel device with clear display) can be easier to use. User groups 22-50 can be more comfortable using new technologies

Figure 39. Comparison of two different devices for I Can Help

The Logica case was an opportunity within APOLLON to perform a third pilot in which we could evaluate some of the lessons learned from the previous pilots and the methodology activities. But in order to replicate a similar set-up, identifying and gathering a similar eco-system as in their home country requires â&#x20AC;&#x201C; due to complexity and scale, much more effort that we could invest during this pilot. On the hand this implied that we were not able to make full advantage of the technology as it was designed and therefore for Logica to asses the core of their system in the new market. In order to do so, much more time in the connect phase as well as the Plan and Engage phase is required). On the other hand, due to good insights of the local Living Lab in their own partner network and understanding of the health system in Belgium, we could offer an alternative setting which not only allows Logica to assess their service (or parts of it) in a new business setting and context, but also help a local partner in experimenting with services that would help them in their daily activities. This bottom-up approach and flexibility is also another important element to take into account in setting up cross-border projects.

It is important to note that the selection of volunteers/user groups can play an important role in the pilot execution. The users should be comfortable with the technologies and devices offered them for the pilot. For instance, 65+ years old users may have difficulties with new technologies, such as iPhone (Apollon I Can Help App is made for iPhones/iPads). While for this age-group of users simple ICT PSP Apollon

99

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 devices with four buttons (Guardian Angel device with clear display) can be easier to use.

User groups 22-50 can be more comfortable using new technologies.

Figure 40 examples of technology

Figure 41 Volunteers on March 23, 2012 at 16:39 Dutch pilot

ICT PSP Apollon

100

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

ICT PSP Apollon

101

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

5. Tools and Methods deployed in the pilots

5.1 Translation tool User interfaces produced as part of a product, whether they are websites or other interfaces, the language can often not be word for word translated. The context of the words and sentences, as well as the ambiguity inherent to language makes it difficult.

When a user interface is designed, there is normally a separation between layout and content. The texts can be changed without having to change the entire userinterface. This makes for easier upgrading. However, sending the texts, often a batch file will not suffice. The problems when translating come from the uncertainty of the context of even simple words, as well as the inherent difficulties of translating language.

Pictures or screenshots are made of the original user interface at every possible state of the device or system. Every state includes the all possible reports and situations that the device or webservice can give. These screenshots or pictures are copied into the slides of a PowerPoint presentation. Also other software used to make presentations can be used. In the notes section under every slide the context and use of any picture is explained, if needed.

Figure 42 User interface in Dutch

The translator places textboxes over every piece of text in the pictures, making it look like it works in the language needed, and puts any comments to particular slides in the notes section of that slide.

ICT PSP Apollon

102

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

Figure 43 The user interface with texts translated and corrected in Finnish

The presentation is then returned to the producer of the product/service who now knows how to translate the texts and can update the system. In this way the context of the words is visible and the functionality can be preserved better.

ICT PSP Apollon

103

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

6. Ecosystem for Health and wellbeing pilots 6.1 Scope and objective Living labs characterize themselves as open environments in which different types of stakeholders are partnering towards the development of new technologies. Implementing projects in the real-life context of users requires a functioning ecosystem. Within Apollon we investigate the feasibility and possible impact of domain-specific cross-border living lab networks. When setting up a cross-border network in the domain of homecare and independent Living and by extension Health and well-being , a considerable challenge will be to match ecosystems and to elucidate and harmonise rules and roles between them.

Within the various homecare and independent living pilots within APOLLON, a homecare solution, which is being piloted in a local Living Lab, is transferred to another Living Lab. A main focus of the pilots is to determine what kind of ecosystem, value network and common approach needs to be in place to conduct cross-border pilots (in the domain of homecare and independent living) and to what extent these pre-requisites helps to do this faster, easier and more efficiently.

To embed this in a cross-border thematic network, it is necessary to determine the ecosystem, value network, actors and roles that needs to be present in a living lab to enable cross-border projects in the domain of homecare and independent living. Especially when the scope is to transfer a specific service or solution from one context to another cross-border country or market this will be one of the main operational elements to tackle.

In order to determine what kind of ecosystem, value network and common approach needs to be in place to conduct cross-border Living Lab projects in the domain of homecare and independent living (scope of this work), we will first briefly focus on the broader Living Lab concept, with specific attention to a) Living Labs active in the domain of homecare & independent living, and b) the cross-border collaboration between Living Labs.

6.2 Setting the context & situating the Living Lab concept Innovation is a high cost demanding process, so an adequate innovation strategy is required. In order to realize this strategy, a better match between technology, society and economy is needed. One of the potential solutions is the concept of â&#x20AC;&#x2DC;user-driven open innovationâ&#x20AC;&#x2122; platforms:

User-driven: in order to help minimizing risks for technology introduction a better understanding of the (potential) user in the innovation process is

ICT PSP Apollon

104

Final Version

Apollon – Deliverable 2.4 recommended. By bringing the users early into the creative process, emerging behaviours and user patterns are better discovered.

Open innovation treats research and development as an open system. This approach places external ideas and external paths to market on the same level of importance as reserved for internal R&D research and development (Chesbrough, 2003).

A living lab has to enable this research, development and innovation process by:

 bringing the users early into the creative process in order to better discover new and emerging behaviours and user patterns;  bridging the innovation gap between technology development and the uptake of new products and services involving all relevant players of the value network via partnerships between business, citizens, and governments;  allowing for early assessment of the socio-economic implications of new technological solutions by demonstrating the validity of innovative services and business models.

One of the main strengths of the Living Lab approach is its ability to merge research and innovation processes with the daily, local, real-life context, close to people in their role as both citizen and consumer. This however does not only mean that technology should be deployed in peoples home, but that it has to be embedded in the existing eco-system and by so reflecting the context in which, in a later stage, the service or product will be commercialized.

In extension this also means that the Living Lab is a collaborative environment in which various actors are involved. This participative and interactive model should have the following benefits for each stakeholder:  for the users in their roles as citizens and the community: to be empowered to influence the development of services and products which serve real needs, and to jointly contribute to savings and improved processes through active participation in the R&D and innovation lifecycle  for the SME’s, incl. micro-entrepreneurs as providers: developing, validating and integrating new ideas and rapidly scaling-up their local services and products to other markets  for the larger companies: making the innovation process more effective by partnering with other companies as well as end-users, which are rooted in active user experiences, increasing ‘right the first time’  for research actors, the economy and society: stimulating business-citizensgovernment partnerships as flexible service and technology innovation ecosystems; integrating technological and social innovation in an innovative ‘beta-culture’, increasing returns on investments in ICT R&D and innovation

Living Labs do not only differ in their composition and approach, but also in the domains they address. We see that currently Living Lab projects are elaborated in various domains, going from digital cities, tourism, e-Manufacturing, eICT PSP Apollon

105

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 Participation, energy efficiency (smart energy systems), future media and content delivery, gaming, intelligent transportation systems to health and wellbeing.

Homecare and independent living and in extension Health and well-being is a very broad domain, which can be described from different point of views (going from prevention and well-being to a more clinical or medical point of view).

Within APOLLON the pilots that were conducted are related to the specific domain of homecare and independent living. The analysis and definition of a common eco-system (see further) is therefore initially framed within that context. When we talk independent living systems (ILS or ICT for independent living) we refer to those systems that support citizens in a wide variety of their day-to-day activities, like for example, sensor-based systems for active daily living, tele-monitoring systems, wearable devices for healthcare applications, personal alarm systems, etc.

6.3 The ecosystem concept

In order to define what is the required ecosystem and how a common ecosystem can benefit cross-border living lab collaboration (in the domain of homecare and independent living), we will first elaborate on some ecosystem theory. For this we will focus business ecosystems, (open) innovations ecosystems and healthcare ecosystems. Based on these concepts, we will elaborate the ecosystem of a living lab active in the domain of homecare and independent living.

Ecosystem thinking

Business ecosystems

Innovation ecosystems

Healthcare ecosystems

Living Lab ecosystem in the domain of homecare & independent living

Figure 44 From ecosystem thinking to the definition of a Living Lab ecosystem in homecare & independent living

ICT PSP Apollon

106

Final Version

Apollon – Deliverable 2.4 6.4

Ecosystem thinking

The central concept of an ecosystem is that living things interact with all elements in their local environment. A natural ecosystem is an environment pertaining to a particular area of physical components containing all the living and non-living organisms in it (Campbell, 2009). In essence this definition means that within an eco-system various partners interact with each other and this in a given context. When transferring this to the living labs, this matches with the basic concept of the Living Lab itself. Per definition, a living lab is an eco-system on its own. In the context of the Living lab various stakeholder will interact in order to develop and evaluate a certain process, product or service. However, often the Living Labs create their own eco-system that not always reflects or is embedded in the actual, existing, natural eco-system.

In that sense Living Labs can be defined more as a business eco-system. The concept of business ecosystem was introduced by James F. Moore (1993) with the description: ‘An economic community supported by a foundation of interacting organizations and individuals—the organisms of the business world.

This economic community produces goods and services of value to customers, who are themselves members of the ecosystem. The member organizations also include suppliers, lead producers, competitors and stakeholders.’ Within the Living Lab projects ad-hoc business eco-systems are being constructed. They are more ‘a dynamic structure which consists of an interconnected population of organizations. These organizations can be small firms, large corporations, universities, research centers, public sector organizations and other parties which influence the system’. Peltoniemi and Vuori (2005, p. 279) Key characteristics of a business ecosystem are according to Peltoniemi (2005):

Figure 45 Characteristics of the business ecosystem (Peltoniemi, 2005)

ICT PSP Apollon

107

Final Version

Apollon – Deliverable 2.4 • •

• •

• • • • •

a large number of interconnected participants (that can be business firms and other organisations) who depend on each other for their mutual effectiveness and survival the members of a business ecosystem work co-operatively and competitively to support new products, satisfy customer needs, and eventually incorporate the next round of innovations (productiveness is a critical success factor) the interconnectedness leads to shared fate: the members are dependent to each other and the failures of others can result in failure business ecosystems should be robust, which means that they have capabilities of surviving when shocks from inside or outside the ecosystem threaten to destroy it (having the ability to transform when the environment changes) business ecosystems should have the ability to create niches for new firms which requires a change in attitudes from protectionist to co-operative business ecosystems rejects both regionality and the concept of industry business ecosystems should be self-sustaining: no government interventions should be needed in order to survive in local or global markets business ecosystems are dynamic structures that evolves and develops in process of time business ecosystem develops through self-organization, emergence and coevolution, which help it to acquire adaptability. In a business ecosystem there is both competition and cooperation present simultaneously.

As the ecosystem evolution is a dynamic process this means that the roles are by no means stable. A business ecosystem gradually moves from a random collection of elements to a more structured community. Every business ecosystem develops in four distinct stages: birth, expansion, leadership, and selfrenewal – or, if not self-renewal, death: 1.

•

•

• •

During stage 1 – the birth stage - entrepreneurs focus on defining what customers want, that is, the value of a proposed new product or service and the best form for delivering it. Some ecosystems that capture the needs of the customers will survive at this stage and develop further into a larger scale.

In stage 2 – the expansion stage - business ecosystems expand to conquer broad new territories. In general, two conditions are necessary for Stage 2 expansion: 1) a business concept that a large number of customers will value; and 2) the potential scale up the concept to reach this broad market. In this stage, the competition with other ecosystems becomes more intensified.

Stage 3 – the leadership stage - – The Ecosystem has an established leader or some leaders, a significant growth and a stable market for depending businesses.

Stage 4 – the self-renewal stage – of a business ecosystem occurs when mature business communities are threatened by rising new ecosystems and innovations.

The Evolutionary Stages of a Business Ecosystem 1

Moore, J.F. (1993) Predators and Pray: A New Ecology of Competition’

ICT PSP Apollon

108

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 Cooperative Challenges

Competitive Challenges

Birth

Work with customers and suppliers to define the new value proposition around a seed innovation.

Protect your ideas from others who might be working toward defining similar offers. Tie up critical lead customers, key suppliers, and important channels.

Expansion

Bring the new offer to a large market by working with suppliers and partners to scale up supply and to achieve maximum market coverage.

Defeat alternative implementations of similar ideas. Ensure that your approach is the market standard in its class through dominating key market segments.

Leadership

Provide a compelling vision for the future that encourages suppliers and customers to work together to continue improving the complete offer.

Maintain strong bargaining power in relation to other players in the ecosystem, including key customers and value suppliers.

Self-renewal

Work with innovators to bring Maintain high barriers to entry to new ideas to the existing prevent innovators from building ecosystem. alternative ecosystems. Maintain high customer switching costs in order to buy time to incorporate new ideas into your own products and services.

Table 15 The Evolutionary Stages of a Business Ecosystem (James F. Moore, 1993)

Within the boundaries of a Living lab and especially the Living Lab projects often this gradual evolution is not possible given the limited timeframe and scope. The Living lab is a vehicle to foster phase 1 of a (new) business eco-system. It gives the companies and organizations a platform to experiment and to identify the appropriate eco-system in which a specific service or product will be further commercialized. Due to the nature of Living Labs it is forced to remain in the first step and can not, by itself evolve to a full business eco-system. This also explains why a common, full grown eco-system within the different Living Labs of a thematic domain is not or at least less feasible.

When creating a business ecosystem there are two important elements to take inot account: Firstly, it is a necessity to create value within the ecosystem in order to attract and retain members in addition to providing growth potential for the ecosystem. Secondly, there needs to be a way to share the value within the ecosystem (Iansiti and Levien, 2004a, p. 91).

During the pilots in the APOLLON project we also experienced that this are two crucial elements in the set-up of a (cross-border) pilot. At least on the project

ICT PSP Apollon

109

Final Version

Apollon – Deliverable 2.4 level there should be an added value for all partners that are involved. We have learned that the expected value should be defined or explicit at the start of the project. This will help to know the stakes of each partner, the engagements they can or willing to do… But as mentioned before, this is related to a specific project and goal. To establish this on a generic Living Lab platform level, as a standard facility to be used for (cross-border) Living Lab pilots, is much more difficult. But in order to create a common eco-system in which various stakeholders have a specific long-term engagement to facilitate projects, such identification and process is required.

6.5 Health (care) ecosystems and health (care) systems

According to the World Healthcare Organization (WHO) health is ‘a state of complete physical, social and mental well-being, and not merely the absence of disease or infirmity. Health is therefore a very broad domain, which is composed of many more factors than health services. Such factors as living conditions, work situation, home life, immediate surroundings, education and social services are only few of those factors that should be taken into account. The health system therefore includes the resources, actors and institutions related to the financing, regulation and provision of health actions.(Murray and Frenk)

When we look at specific health eco-systems, we see that this is a relatively new concept in research, and there is still a lot to be done to establish it. Laihonen (2006) defined the (Finnish) health ecosystem as ‘a dynamic structure which consists of an interconnected population of organizations that influence municipal health care. These organizations are e.g. municipalities, private health care organizations, third sector organizations, hospital districts, inhabitants of municipalities, government and research institutions that are used for information steering or for medical purposes’. Important here to the context of the health ecosystem, the government has to be seen as a part of the ecosystem and not as an external force.

The complex structure of health and the various layers within society it is embedded makes it also very difficult to create a common eco-system that is able to cover all the aspects that health touches. This is also acknowledged in how a health eco-system as such is defined. It is clear that in relation to other domains, the health and well-being domain requires a quadric-helix approach in which all stakeholders are involved. The specific (and sometimes dominant) role of the public actor (be it government or public structured organizations) is crucial within the domain of health and well-being. This is also demonstrated in the various pilots of APOLLON. In each of the pilots there were initially no public actors involved, but in the deployment it was required to have them as an active partner.

6.6 The health care system and long-term care system: an overview Long term care systems in Belgium, Finland, Spain and the Netherlands are described in the European ANCIEN project - www.ancien-longtermcare.eu ICT PSP Apollon

110

Final Version

Apollon – Deliverable 2.4

Figure 46 Overview chart of the Belgium Health System

Based on the above findings, we define a Living Lab ecosystem as ‘a dynamic structure of interconnected public-private partnership organizations, which consists of research institutes, companies, governments and final users, plus the socio-economic and contextual environment and including the health institutional and regulatory framework’’.

In a living lab these partners will often be identified on an adhoc, project base which result in a temporary (ad-hoc) ‘value network’ (Amit & Zott, 2001) or ICT PSP Apollon

111

Final Version

Apollon – Deliverable 2.4 ‘ecosystem’ (Iansiti & Levien, 2004). Creating such networks have been recognized as an important part of open innovation cooperation (Chesbrough, 2003; Maula et al, 2006; Vanhaverbeke & Cloodt, 2006).

Figure 47 Position of a Living Lab in Homecare and Independent Living

Ecosystem specific characteristics Socio-economic and contextual environment • • • •

Contextual differences (cultural differences, attitudes of users towards ICT in homecare and independent living, etc.)

IT investment in the country/region market and product maturity technical issues like fixed or variable IP-addresses

Health institutional and regulatory framework • • • • • • • • • • •

the organization of the healthcare system (funding) government involvement personal data protection and privacy laws ethical board regulations and processes patient rights laws dependent people laws healthcare laws and local regulations (municipal/country)) health insurance provided by employer, public or private level of health care organization (municipal, regional, federal) medical standards and clinical practices integration with other services

ICT PSP Apollon

112

Final Version

Apollon – Deliverable 2.4 Table 16 Ecosystem specific characteristics

6.7 Actors and roles in a living lab ecosystem active in homecare & independent living Within the domain of Homecare and independent living, services are organized and funded differently from country to country, sometimes even from region to region. Therefore, we need an abstract model with clear identification of the roles that are necessary, in order to elaborate a living lab project in the domain of independent living systems. This is also acknowledged by Iansiti and Levien (2004) that states that complex ecosystems, such as within health, needs to subdivided in a specific groups or business domains in order to have a good overview of the sector as a whole.

The identification of generic actors within our domain is based on different studies in the field of independent living systems (Van Ooteghem et al; GaBner & Conrad; Veys). The most important elements of these studies are shortly mentioned below.

Van Ooteghem et al. (2007) selected various actors in their eHealth business model for independent living systems. They defined two major blocks: the players financing the system (the government and the health insurers) and the actors involved in offering the eHealth services to the user. They identify the following actors: •

•

• • • • • •

The government plays a very important role in launching, supporting and distributing the eHealth service, whether is it at local, country or European level.

Mainly this will involve taking care of new regulation and financial support.

Health insurers offer financial support in case of medical treatments, medication or other facilities or services, specifically for medical reasons, must be covered. Extra insurance can be concluded with private companies for specific risks or ailments.

The end users of the system can be split in three categories: the patient, the non-professional carers and the professional medical practitioners.

Equipment manufacturers will develop specific hardware compatible for offering the different functionalities.

Wholesalers or retailers will distribute the hardware. eHealth service providers will take care of the software development required for offering the services.

A network provider is required for transmitting information from the patient to the other users within the system.

Mediators, such as Social Service Departments, home care shops, local services centres and hospitals are market players in direct contact with end users, to whom they offer the service.

ICT PSP Apollon

113

Final Version

Apollon – Deliverable 2.4 GaBner and Conrad (2010) identified the following stakeholders in the market of AAL (ambient assisted living) in Europe: • • • • • • • • • • • • • • • •

Building and housing industry Consulting (advisory bodies) Government Local or regional authorities Hardware/software/device providers Service providers Providers of AAL products and services Healthcare providers Medical institutions/hospitals Industry Insurances NGO’s Universities Non-university research organisations Safety Others

Veys identified in the IBBT TransCare project the following generic actors: • • • • •

External developer: development & production of the application Home care organization: offers the care services at home Connectivity provider: offers the electronic communication network End user: uses the services Government

Based on these literature studies, we identify the following generic actors that can be involved in living lab projects that focus on independent living systems in homecare.

ICT PSP Apollon

114

Final Version

Apollon – Deliverable 2.4 Users •Patients and citizens •Informal care givers •Professional health care providers Authorities (and subsidized health care sector) •Government •Regional and local authorities •Professional healthcare providers •Health insurer (public) Academia •University •Research center Industry (SME & large companies) •Connectivity provider (infrastructure & network provider) •Developer •Health care suppliers •Housing industry •Health insurers (private) Table 17 generic actors in the living lab ecosystem active in homecare and independent living

6.8 Towards a ecosystem for Living labs dealing on Independent Living and Health When taking the above information into account, as well as the experiences during the various pilots within Apollon we do see that the establishment of a common, fixed eco-system for Living Lab operating cross-border is not feasible.

Due to the fact that the Health sector in each country or even region is organized in such a different way and the legislation, rules and business processes therefore are very heterogeneous, the Living labs are forced to follow a projectapproach in establishing the necessary partnerships and conditions for a Living Lab project. However, we do think that – due to the nature of Health there are some common elements that are part of the health eco-system. More specifically the actors – and to be precise the roles that they fulfil in this, they are often common. They can be organized or structured in a different way in each region, but the tasks that need to be fulfilled are similar. For example when setting-up a project on home-care you will have in each country a patient-group, a homecare-organisation… involved in the project in order to have successful deployment. The kind of home-care organization and whether it is a public or private organization, that can differ.

Therefore we have defined a common eco-system structure based upon the roles that are required for a (cross-border) Living Lab project and the responsibilities that are related to this role. The reason for doing so enables us to identify in a common cross-border Living Lab project the different tasks and the roles that are required, despite which specific actor that would perform this. for example; when you need an informal caregiver in the project to assist the patient in the weekend, this can be done by various groups, but all with the same tasks. In ICT PSP Apollon

115

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 Belgium for example it can be the relatives of the patient while in Finland it is a public supported volunteer organization that would take that role. In other words the task and responsibilities are matched one-to-one but not the specific actor (what often seems to be the case in eco-systems). Consequence of this approach is that the Living Lab cannot set-up an eco-system with a set of fixed partners, but has to have a network of actors that they can activate and involve on a project base.

Below we have, based on an actor-analysis, identified the necessary roles and responsibilities to which a Living Lab has to have access to. If they can cover each of these (not all by themselves, but through partnerships) they are able to deliver a complete service for companies. Goal is that every Living lab can engage this network and by so offer a same service to users of the Living Lab. If so, Living Labs active in the thematic domain network should be able to (1) have a similar service offer, (2) rapidly and efficient engage the most appropriate local actors.

Figure 48 generic actors in a living lab active in homecare & independent living

â&#x20AC;˘

Patients & citizens: Patients and citizens are a central and crucial actor in the living lab, as the innovative services or projects aim to promote their health, wellbeing and independency.

ICT PSP Apollon

116

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 â&#x20AC;˘

Informal caregivers: Very close to the patients and citizens, we define the informal caregivers also as a central actor in the living lab in the domain of homecare and independent living.

Family

...

The community

Friends

The informal caregivers

Associations of users and informal carers

Neighbours

Volunteers (facility for sitting services) Community workers

Figure 49 the informal caregivers in the homecare and independent living domain

â&#x20AC;˘

The professional healthcare providers: The professional healthcare providers are important actors in the living lab with focus on home care and independent living, as they are the key actor in the health and care service delivery towards the patients and citizens. One or more of the following actors can be involved within living lab projects that focus on independent living systems. These actors can be involved as project based partners (depending from project to project), but even better is to involve them as a fixed partner in the living lab ecosystem.

ICT PSP Apollon

117

Final Version

Apollon – Deliverable 2.4 GP

Home help and additional home care

Individual care providers

Social services of the health insurance funds

Home nursing

The professional healthcare providers

Facilities for sitting services

Residential care

Cooperation initiatves in primary health care

Emurgency services (hospitals)

Regional services centres

Preventive health care providers

Local services centres

Figure 50 the professional health care providers in the homecare and independent living domain

• •

• • • • • •

The government: The term ‘government’ is used for authorities, institutions or organizations responsible for the development and performance of policies on the national level, such as national ministries or health institutes.

The regional and local authorities: The term ‘local or regional authorities’ refers to institutions and organizations responsible for the development and performance of policies, yet on regional level only (cities, municipalities and councils).

Health Insurers: Public health insurance funds & Private (health) insurance companies Research: Universities, Research centers, Study service of the professional health care organization or health insurance fund Developers: Medical device manufacturers, Software developers, Hardware developers, Pharmaceutical companies Connectivity provider: Telco Health care supplier: Housing industry:

6.9 Roles in a living lab active in homecare & independent living Description of the role

Generic actors that can fulfill the role • • •

Development of the innovation (independent living system or service)

ICT PSP Apollon

118

Developer Health insurer Professional healthcare providers Final Version

Apollon – Deliverable 2.4 Facilitate the testing of the innovative service by the end users

•

Living lab

Test the innovative service and provide feedback towards the living lab

• • •

Provide the health and care services at home

• • •

Patients & citizens Informal caregivers Professional healthcare providers

Provide information about homecare and independent living to the patients and citizens

• • •

Search and select the test users

•

Offer financial support (medical treatments, medication, facilities or services)

• • •

Setting up and implement the research

• • •

Management of the data (administrative data, healthcare related data, medical data) and follow-up in case of emergency

• • •

Customer service and maintenance of the ICT applications in the homes

Professional health care providers Local authorities/municipalities Informal caregivers Local authorities/municipalities Health insurance funds Professional healthcare providers Health insurance funds Regional authorities Local authorities Living lab

Research organization University Study service

Professional health care providers Local authorities/municipalities Informal caregivers

Installation of the ICT applications in the homes

•

•

Connectivity provider

Transmit the information from the patient to the other users within the system

•

Connectivity provider

Development and management of health care regulation

• • •

Communicate regulation to the patients & citizens

• • •

Government Regional authorities Municipalities

ICT PSP Apollon

119

Connectivity provider

Government Regional authorities Municipalities Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 â&#x20AC;˘

Communicate the results of the innovative pilots towards the living lab ecosystem Table 18 Roles and Actors

ICT PSP Apollon

120

Living lab

Final Version

Apollon – Deliverable 2.4

7. Recommendations for Cross Border Living Lab collaboration 7.1 Privacy Especially within the domain of health and wellbeing we noticed that privacy is, maybe more than in other domain, a crucial element that has to be taken into account. As by default you are working with users as individuals you are confronted with privacy-issues. These issues are situated on various levels. First, it is necessary – in order to provide the required services, that you not only have a good profile of the user but that the service is almost always ‘personalised’.

Second, often you are capturing very sensitive data (even medical (related) data). For this latter – each of the countries have different rules for that. Eg. in Belgium it is required that a medical practitioner is involved that is responsible for the handling of the medical data. Third, also specific to the domain of health and well being, there is a high level of data exchange required between various stakeholders in the process in order to provide the services.

It is required in a cross-border Living Lab projects that from the start there is a good overview of all the data that is being collected and/or used during the pilot.

This will enable you to (1) identify the responsible actors for each data-set, (2) to be transparent to the end-users on which data is being collected from him/her and (3) to organize the ‘official’ agreements between the partner that will allow the exchange of data, all with respect to the privacy of the users and the current legislation and rules.

The Living Labs operating in networks should all be compliant to the specific privacy rules that are required, both from an operational as from a process point-of-view. In the first it will be the Living Lab itself that will take responsibility with regard to the collection and safeguarding of the data. In the second, the Living Lab knows all the steps to guide partners in the project to assure that their service or tool will be in line with current legislation.

The element of privacy is something that has to be safeguard during all the phases of the cross-border pilot. But especially during the plan and engage as well as the support and govern phase it is important to pay special attention to privacy. During the plan and engage the partners will have to identify who is capturing what data, who is owner of that data, which security measures have been taken to protect these… Second, during this phase the actors will have to make the required agreements for exchanging the data. Within the support and govern phase it is important to check that during the set-up of the pilot ICT PSP Apollon

121

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 everything is being deployed with respect to the privacy and according the agreements and rules.

7.2 Liability Liability is a very complex issue in the health and wellbeing field. But there are significant differences within this domain. Nonetheless, a clear distinction should be made between clinical, medicalized, healthcare and other surrounding, softer areas (home care, wellbeing services, etcetera).

In the case of clinical care, the barriers for open pilots are very high in terms of liability. There are strict and complex regulations for device certifications, licensure requirements for most professional profiles, rigid procedures for testing, data gathering and analysis and so on.

This doesnâ&#x20AC;&#x2122;t mean that projects or proposal from that domain should be discarded for the living lab approach. It simply means that a very detailed analysis of all liability issues has to be made upfront. This can entail a bigger effort than sorting out other matters such as IPR deals or coordination issues.

All European countries have specific regulation and registration requirements for clinical trials (this includes not only drugs but also any technology or procedure that is therapeutic in nature). These rules cover aspects from user selection, ethical concerns, specific research goals and other relevant aspects of the pilot.

In less core areas such as home services and wellbeing the issues related to liability are less of a burden. Informed consent documents and clear statements of purpose and scope for the services will cover most of the requirements.

Special attention has to be paid to services that are related to (or easily mistaken with) emergency alerts and warnings. In most European jurisdictions there are specific legal requirements and designated entities to manage these kind of alerts and any pilot in this initiative must have a clear delimitation of responsibilities and the necessary coordination provision with these designated operators.

7.3 Ethics

There are European wide but also national rules with regard to ethical issues for citizens when a study collecting their information is carried out. The Charter of Fundamental Rights of the European Union reflects the fundamental ethical principles for dignity, freedoms, equality, solidarity, citizens' rights and justice.

The national rules vary. E.g; in Finland the National Institute for Health and Welfare is granting an ethical permission for databanks that are confidential, the different hospital districts have the right to grant the ethical permission when ICT PSP Apollon

122

Final Version

Apollon – Deliverable 2.4 medical studies are carried out. The Helsinki City Health Services has their own ethical committee and a written permission is needed to collect any type of information of their customers. The ethical permissions are also hierarchical.

Before requesting the permission from the Helsinki City Health Services, a written answer is needed from the local hospital district that their ethical permission is not needed.

Participation in a project must always take place on a voluntary basis. The participants will be properly informed about the project, its objectives and procedures and a written consent is required from them. They also need to be informed that they are at any stage allowed to pull out from the project.

When collecting the data, it is important that the data protection issues are well obeyed. The researchers need to describe how the data is stored, who is able to work with it and ensure that identities of the individuals will not be revealed.

Researchers collecting sensitive data will be required to sign non-disclosure agreements.

7.4 Checklist of requirements Based on deliverable D2.1 Requirements and the input from the different pilots, we updated the list of requirements.

Defining the context • • • • •

Creating a scenario Description of the operational set-up Description of the technical set-up Pilot versus commercial project Dictionary of important terms and concept to make sure everyone talks about the same things • Presence different stakeholders Requirements

• Technical requirements E.g., do not assume that people have the same perception of something.

A broadband connection in one country is not the same as in another.

Therefor don’t just state: “a broadband internet connection is required” but give as many details as possible that might be important (eg. min. speed, type of IP-address, NAT or not etc…)

• • • • •

Installation requirements Organisational requirements e.g., support and helpdesk, manuals, training,…

Functional requirements Rules, regulations, ethics and social norms

Research set-up ICT PSP Apollon

123

Final Version

Apollon – Deliverable 2.4 • • •

Objectives and goals Research requirements User profiles

Initial required eco-system • • • •

Description Requirements Stakeholders Rules, regulations, ethics and social norms

7.5 Safety

Especially in healthcare safety is one of the biggest concerns. You are dealing with real people so if a solution fails it could result in death. There are heavy rules and regulations in the use of equipment, ethical and client committees will have to agree with the solution before you can do anything. The difficult part is that the strictness of the safety for the client is very different per country or even per care organization.

It does not mean that safety counts for all solutions e.g. a weight scale that sends the data over the internet is not life treating if it fails. But a emergency pendant that fails could have a horrible effect.

7.6 Maturity

Maturity it does not always mean that the solution is reliable! Mostly after a few years the biggest bugs should be gone and basic functions should be stable. This is good age for a living lab to help companies with a cross border project. You don’t want to help them debugging the basic functions. Make sure that the companies have the solution in use for at least one year in a fully operations organization with real clients!

To test the maturity read the part about Reliability.

7.7 Reliability

Test everything, do not believe the brochures. Reliability is something you have to see for yourself. Let suppliers show there solution at your site. Be critical because with your own tests you get enough trouble and you don’t want to debug the suppliers solution.

The best steps for testing is:

1. technical component test, let technical expert check the modules. E.g. If it’s done with up to date equipment, if there are interfaces that work with other solutions?

ICT PSP Apollon

124

Final Version

Apollon – Deliverable 2.4 2. functional component test, let a none technical user test the system, e.g. does it understand the system without help from others, is the solution doing what the user was expecting?

3. lab test, test the full system in the office and let some colleagues work with the solution.

4. friendly user tests, place the system for a longer period in the home of people you know via via and are close to the target group.

5. small real user test, possible you work with a care organization to get users.

Start with a small test because the organization needs to get familiar with the procedure.

6. big pilot. After you’ve evaluated all phases and implemented the most of your lessons learned the solution is ready for a big implementation.

7.8 Costs

An important aspect in doing business is of course the cost of the project. But not only the costs for the project itself are important, also the surrounding business model for putting your product or service in to the market is relevant. This means that taking into account (local) rules and regulations is needed from the beginning.

Especially when exploring new markets, other than the home market, the local “infrastructure” in which healthcare is situated and its stakeholders can differ significantly. For instance, in Belgium it is assumed that most healthcare related products and services are cheap or even for free and by consequence available to everyone. Also depending on the region you live in, the healthcare is structured in such a way that you can receive extra funding from the local governments.

Doing business in healthcare means that your business will be strongly related or linked to certain paying models, repayment issues, stakeholders such as social security companies (“mutualiteiten” (<Dutch)). In other countries healthcare insurance companies are more important and weigh heavier on the cost model.

To account for this important aspect, make sure you know the local eco-system and its cost-related organizations.

Another issue in doing cross border pilots and cooperation is the fact that you have to make clear in which modus this pilot is taken place. Is this pilot part of a real market situation or is this rather a trial situation with volunteers, or even something in between. Depending on the situation, the expectations from all involved partners will be different. Thus make clear from the beginning what those expectations are.

7.9 Trust

In general we understand trust as reliance on another person or entity to not engage in potentially harmful behaviour while providing the expected – and visible – benefit. This combines confidence in the aspects that technology works as expected, is not privacy abusive and respects human dignity and does not undermine the security of the user. In practice, trust often boils down to users of services who evaluate the expected benefits against the perceived risk, noting that this may not necessarily correspond with the actual risk. One needs to ICT PSP Apollon

125

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 consider both aspects and divide risk in two categories â&#x20AC;&#x201C; risk associated with security and with privacy, as the economic models for security and privacy are different. Trust also needs to be evaluated according to its constituent components accountability, transparency, anonymity and traceability.

Trust is involved for interaction with various elements of the digital world, such as on devices that should be safe, on service and product providers to guarantee sufficient protection and on actions that should be transparent and not breach privacy. Furthermore, there should be safeguards against purposeful or accidental misuse by governments, oneself, malware and in general 3rd parties that may be involved, perhaps even without legitimate parties knowing.

When applied to the Living Lab pilot cases, i.e. of the ADL (Innoviting case) we can say that the main issue w.r.t. trust of the solution depends on the trust between the caretaker and the elderly person. When the relationship is good between the, the elderly person trusts also the technical solutions proposed by the caretaker. Though there are still some questions the elderly has around privacy aspects, i.e. who can see what data. Once this is clarified, the trust in the solutions by the elderly person is good. During the pilots we have not experienced any purposely hampering by the elderly with the system due to lack of trust or privacy concerns. One of the factors that one should be aware of is the fact that elderly with dementia often forget that they are observed. Extra care should be given to continue guaranteeing privacy at the same level throughout the whole lifecycle of the system usage.

7.10 Rules and regulations

To avoid dealing with the specific rules and regulations in the medical setting, the ADL system has been used in a closed private setting. As the goal of the pilot was to determine the attractiveness and match of the solution with the needs of the people, we did not want to complicate the technical solutions with rules and regulations restricting the flexibility of the technical solutions. Using a closed environment (private/family) the trust and privacy issues were solvable, while guaranteeing the security of the data-access through technical standards and by separating the data from the actual identity of the observed persons. By not conforming to all rules and regulations enforced from the medical councils and insurance companies, there could be no financial reward for using the system from healthcare insurance. This simplified the administrative procedures but did not give us any insight in the difficulties (technically and administratively) when we do want to switch towards financial compensation from health care insurance companies.

7.11 Access to end-users

Living Lab projects are by definition a collaboration between various stakeholders. In a quadric helix model users, industry, public sector and the research world work together to test and validate new services, products or processes. In the domain of health and well-being these are always oriented to ICT PSP Apollon

126

Final Version

Apollon – Deliverable 2.4 the end-user. Therefore this group is crucial in the whole process. But as often the projects that are subject of the (cross-border) Living Lab do require the engagement of a very specific target group. But engaging these groups are not that easy, especially in a cross-border collaboration. Not only you have to be able to identify the right groups, it is required to access them in the right way. Local actors, that are a trusted party and that work on a regular base with the target group are a necessity in this process. They are not only required to engage the end-users, but also to manage all the interactions with the end-users during the project.

During the cross-border collaboration the remote Living Lab is a crucial actor in identifying the right organisations that can fulfil the role of the trusted party and by so act as a gateway between the project and the end-users. It is crucial that this actor is fully engaged in the project and they also have a benefit in participating in the project. In other words these trusted parties cannot be forced in a pure executive role. Often the activities required for conducting the project and the research activities demand an extra work force.

As said, the trusted party will be the gateway to the end-user throughout the whole project. They will have to facilitate the following elements that are crucial in engaging specific target groups: Detecting the right profiles within the target group. Within a test-group you will have a huge diversity in profiles, especially on the level of the independency, the abilities… Through their regular contacts with their users, they will be best placed to selected the test-users (taking into account the project objectives) •

•

•

•

Approach them in the right way: each actor / group needs to be address in the proper way, with the right message, tools and approach. They will have to translate the objectives in a communication approach that fits the most.

Assess the limitations of the target group: both in terms of the interaction with the new service, product or process, as well as with regard to the research activities (for example to determine the amount of questionnaires, type of questions…)

Performing the direct interaction with the test-users. In order to receive feedback in the most efficient way, the local actor or organization will (with the assistance of the other project partners) need to retrieve the feedback of the users. This actor knows their users, knows their language, can address them in the proper way. As they are a trusted party, users will also provide more honest and true feedback.

To embed the research activities in their existing processes. This is not only important from an organizational point of view, but also for the end-users as this will be experienced as less intrusive.

ICT PSP Apollon

127

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 The collaboration with local actors, and especially care-organisations, is a requirement when you are setting-up cross-border Living Lab pilots. The remote Living Lab will act as a broker to identify the most suitable organization that can assist in the execution of the pilot. But it is important that the care-organisation becomes an equal partner in the project, meaning that there is also clear added value for them in joining and participating.

ICT PSP Apollon

128

Final Version

Apollon – Deliverable 2.4

8. Conclusions The objective of WP2 was to assess to what extent a common eco-system could benefit a cross border network of Living Labs within the domain of Homecare and Independent Living. To do so, WP2 has executed three different experiments in which each time an existing technology was transferred to a new context. The hypothesis was that, if a similar eco-system would be present, this transfer would go more easy and efficient.

However, these transfers have learned us that working with a common ecosystem as such isn’t feasible for a number of reasons. First, of all, within the domain of Health (as an extension of the Homecare and Independent Living), the eco-system – in all of its dimensions, is too specific for each country. Even within countries there can be too many differences. Second, the eco-system comprehends more then only a network of partners active in the domain. It consist also of contextual factors such as rules and regulations, business structures… Three, for performing a cross-border pilot it is necessary to find a good match between the various stakeholders. This is often not possible within a predefined eco-system.

But, the pilots have also clearly indicated that organising such an eco-system is a necessary condition in setting-up cross-border pilots. However, different aspects have to be taken into account. First, the eco-system should be built around roles and responsibilities. This means that a pilot needs to be divided in sub-activities for which the most appropriate actor needs to be found. Second, the involvement of these partners should be driven by a clear need and a fit in the existing portfolio of roadmap of a stakeholder. Third, as much as possible this should be a bottom-up process on all levels. This means that there has to be good needidentification on the local level, and that these needs are then being ‘shared’ within the community. Subsequently a matchmaking process needs to be in place.

Within the process of the eco-system and cross-border pilot the Living Lab has clearly been identified as a good, neutral partner to facilitate this process from start to end. This includes on a first level the need-identification and matchmaking. Second, the Living Lab will also play a more active role in the deployment of the experiment. Here the role of the Living Lab is definitely challenged as it is expected that they will also act as the ‘ambassador’ of the service that is subject of the experiment. This goes often much further then what some of the Living Labs offer as a service.

When we look at the overall APOLLON methodology, we can argue that the four main phases that have been identified – connect, plan and engage, support and govern and manage and track, are very good steppingstones to set-up a crossborder pilots (which in extension – on a project base - could also be seen as cross-border networks). As each of the experiments is confronted with different challenges, the way in which this approach is being deployed various. Still we have identified some common steps or activities that need to be done in order to ICT PSP Apollon

129

Final Version

Apollon – Deliverable 2.4 successfully transfer a technology from one context to another. First, a good requirement and value analysis needs to be performed in which not only the technical aspects are being investigated, but also the contextual elements and the expectations of each of the stakeholders. Second, the contextualisation and testing of a service cannot be taken as granted. This has to be done properly, tested in boht lab as real life setting… Techniques like friendly-user tests etc… are a necessary step in the process.

Finally, when looking at the different actors that were involved in the three experiments (Living Labs, SMEs and Large enterprises) each of those groups gained a lot of insights on how cross-border pilots work, the impact that this has on their organisation, the context, conditions and bottleneck of entering a new market and working with a new eco-system. Next to these general, common outcomes, we also see some group-specific ones: •

•

•

Living Labs: they enriched their current portfolio with new approach tools and methods, better insights on stakeholders needs in cross-border pilots within the domain of Homecare and Independent Living. They gained knowledge on very domain specific aspects to be taken into account and how to deal with them.

They extended their own local and international network and how to attract, involve new stakeholders and create a local eco-system. Especially towards SMEs they learned more on how to engage them. They identified new roles and type of service that they can fulfil in cross-border pilots and networks. Finally, the activities also had a positive impact on their position, both national as European wise, resulting in new partnerships, projects…

SMEs: in the first place they have gained important knowledge with regard to the impact of such cross-border pilot on their organisation. Participating in such cross-border platform resulted in much more effort, on domains they had not foreseen, then originally estimated. Second, it helped the SMEs not only to adjust their technology or service as such, but also the business model, their strategy and internal processes. This Third, the insights on the cross-border level also enabled them to position themselves better (with a stronger product) in the local market. Finally this created visibility on national as on European Level, resulting in some specific leads for further projects or business cases.

Large Enterprises: For the large enterprise, the cross-border pilot enabled them to gain insights in the benefits of the Living Lab and cross-border pilot on the level of the evaluation of a service, but also on the level of re-thinking the concept. This resulted for example in the exploration of a new business model.

The cross-border network and pilot is for them a good instrument to explore new markets, business opportunities and to get in contact with new stakeholders in an open, neutral and safe environment. For them the Living Lab is a key-partner in this process that can guide them in the local eco-system.

During the APOLLON pilot, the large enterprise was able to identify concrete new market opportunities and extend their current service in such way that it becomes available for market offering.

ICT PSP Apollon

130

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 The lessons learned from the experiments and the more domain specific elements are valuable insights when performing a cross border pilot within the Homecare and Independent Living. As health is structured differently is every country, an harmonization or a common ecosystem approach is not feasible. This has therefore resulted in an ecosystem analysis tool for understanding and quantifying the roles of various actors within a certain ecosystem tasked with providing, or potentially being able to provide the needed functions for the pilot set-up. The elements of the ecosystem are not limited to differing conflagrations of organizations and roles but also include technical standards, Legal regulations, ethical, social and moral differences.

It is clear that performing cross-border pilots and working in a cross-border network facilitated SMEs to enter foreign markets. The Living Labs as facilitator of establishing a local ecosystem and providing access to local stakeholders are considered as a good instrument and easy way to do so. The Living Labs specialized in Health, Homecare and Wellbeing has a clear role as both the test bed for innovation and as a central point in role of innovation intermediary.

The activities within this Apollon WP2 has demonstrated the difficulties of operating in a health care domain cross-border pilot and created solutions for various problems that occur. With this deliverable we hope to inspire those who endeavour comparable projects and give them, with these insights a head start.

ICT PSP Apollon

131

Final Version

Apollon – Deliverable 2.4

9. References •

• • • • •

•

• • •

• •

Laihonen, Health ecosystem as an interpretation framework for knowledge flows.

Paper presentated at the 7th European Conference on Knowledge Management http://books.google.be/books?id=ni(ECKM, 2006).

Online available: iJFwZ2k8C&pg=PA292&lpg=PA292&dq=laihonen+health+ecosystem&source=bl&ot s=_Qe1UeP1sS&sig=okw0TYVA7O8nksta2EJd3bEhL0&hl=nl&ei=3BWwTaDQAcafOp iJrY4J&sa=X&oi=book_result&ct=result&resnum=5&ved=0CDwQ6AEwBA#v=onepa ge&q=laihonen%20health%20ecosystem&f=false Campbell, Neil A. 2009. Biology Concepts & Connections Sixth Edition, page 2, 3 and G-9.

Rivard-Royer et al.; Healthcare Ecosystem: Linking Logistical Flows and Clinical Flows, 2003, HEC Montreal Gillick, Medicine as Ecoculture. Annals of Internal Medicine, American College of Physicians, 2009 L.D. Serbanati et al. Steps towards a digital health ecosystem. Journal of Biomedical Informatics, 2011 Maracine, V. and Scarlat, E. “Dynamic Knowledge and Healthcare Knowledge Ecosystems”. The Electronic Journal of Knowledge Management Volume 7 Issue 1 2009, pp 99 – 110, available online at www.ejkm.com Peltoniemi, Business ecosystem as an organization population model (chapter 5 out Business Ecosystem: A conceptual model of an organization population from the perspective of complexity and evolution Serbanati LD et al. Steps towards a digital health ecosystem. J Biomed Inform (2011), doi: 101016/j.jbi.2011.02.011 http://www.talentfirstnetwork.org/wiki/index.php?title=Ecosystem_references http://books.google.be/books?hl=nl&lr=&id=niiJFwZ2k8C&oi=fnd&pg=PA292&dq=keystone+healthcare+ecosystem&ots=_Qe1UfL ZoV&sig=2dMyJ0oWyOGaemoBjHiImC5Dxcc#v=onepage&q&f=false Proceedings of the 7th European Conference on Knowledge Management (ECKM 2006). Health Care Ecosystem as a Network of Knowledge Flows, Harri Laihonen Yin, R. K. (1989). Case Study Research: Design and Methods. Applied Social Research Methods Series, 5. Newbury Park, CA: Sage Publications.

ICT PSP Apollon

132

Final Version

Apollon – Deliverable 2.4

10.

ANNEXES Annex 1 professional health care providers in Belgium

 The general practitioner (GP)

The general practitioner is the preferred entrance point for health care in the Belgian health system. The vast majority of physicians work as independent self-employed health professionals. In a given area, GP circles are responsible for local health policy, collaboration with other health care providers and hospitals, and the organization of out-of-hours primary care.  Individual care providers (others than GP’s)

General practitioners, verzorgenden, etc.

pharmacists,

physical

therapists,

nurses,

dieticians,

 Facilities for home help and additional home care

A facility for home help and additional home care (‘diensten voor gezinszorg en aanvullende thuiszorg’) sends someone to people’s homes to provide: o o o o

personal hygiene services (washing, clothing, nursing, etc.), household help (cooking, washing and ironing, etc), psycho-social and pedagogical support and assistance (company, contact point, referral to other care providers, etc.), or cleaning services.

Anyone who requires help at home due a specific care need can call on a facility for home help and additional home care. This care need is determined through a social examination. The facilities for home help and additional home care can be public or private. The following facilities are recognized by the Flemish Agency for Health and Care.

•

Public facilities for home help and additional home care are the Public Centres for Social Welfare (‘OCMW’s’) connected to cities or towns.

ICT PSP Apollon

133

Final Version

Apollon – Deliverable 2.4 •

Private facilities for home help and additional home care are: Vzw De Regenboog, Vzw Familiehulp, Vzw Familiezorg Oost-Vlaanderen, Vzw Familiezorg WestVlaanderen, Vzw Gezins- en bejaardenzorg Asabbane Mina, Vzw Gezinszorg Villers, Vzw Joodse Centrale, Vzw Landelijke Thuiszorg, Vzw Liers Centrum voor Gezinszorg, Vzw Onafhankelijke Dienst voor Gezinszorg, Vzw Onafhankelijke Thuiszorg Verenigingen, Vzw Pajottenlands Centrum – Leda, Vzw Sociaal Centrum Lier, Vzw Solidariteit voor het Gezin, Vzw SOWEL, Vzw Thuishulp, Vzw Thuisverzorging de “Eerste Lijn”, Vzw thuiszorg vleminckveld, Vzw Wij blijven Thuis, Vzw Wit-Gele Kruis van Vlaanderen - Beter Thuis.

More information about these facilities: http://www.zorg-engezondheid.be/adressen_gezinszorg_en_aanvullende_thuiszorg/

 Facilities for home nursing

A facility for home nursing (‘diensten voor thuisverpleging’) is responsible for the quality, cooperation and continuity of home nurses. A facility groups a number of home nurses who either work for the facility itself as an employee or cooperate with the facility as a self-employed person. This allows the nurses to work together more efficiently and to help or replace each other whenever necessary.

Home nursing is done by nurses. Apart from nursing care these nurses also pay attention to family and social circumstances. In addition, they help people at home in terms of prevention, health information and health education.

Facilities for home nursing that are recognized by the Flemish Agency for Health and Care are for instance: Wit Gele Kruis (units per province), Onafhankelijke Thuisverpleging Vlaanderen, Thuisverpleging De Voorzorg, Mederi, Solidariteit voor het Gezin, Thuisverpleging Bond Moyson, etc.

More information about the facilities for home nursing: http://www.zorg-engezondheid.be/Zorgaanbod/Thuiszorg/Diensten-voor-thuisverpleging/

 Local services centres

Local services centers (‘lokale dienstencentra’) provide information, recreational and training activities. People can turn to these facilities with questions about home ICT PSP Apollon

134

Final Version

Apollon – Deliverable 2.4 care. Information moments are organized, as well as hobby activities and courses.

These activities are specifically aimed at increasing the participants’ ability to do things independently and at reinforcing their social network. A local services centre is specifically oriented towards people who have only recently developed a care need. The provision at the services centre encourages their ability to cope independently and allows them to become familiar with other types of home care as well. Local services centres offer also advice about personal alarm systems, they provide such systems and they offer the service Uitlenen van personenalarmtoestellen en organiseren van de dienstverlening van personenalarmcentrale More information about the local services centers: http://www.zorg-engezondheid.be/Zorgaanbod/Thuiszorg/Lokale-dienstencentra/

 Regional services centres

Regional services centers (‘regionale dienstencentra’) give information and training through group activities. These activities are intended not only for the elderly, but also for informal carers and volunteers. With respect to volunteers, they have the specific task of balancing supply and demand in volunteer care. In addition, they offer information and advice on all kinds of material and immaterial aids (including support technology, house adaptations, personal alarm systems, occupational therapy …). The regional services centres also assist by bringing these services to the users. Finally, the centres organise consultation between the different care providers (such as GP, physiotherapist, home nurse, etc) about an individual patient.

More information about the regional services centres: http://www.zorg-engezondheid.be/Zorgaanbod/Thuiszorg/Regionale-dienstencentra/

 Facilities for sitting services

A facility for sitting services (‘diensten voor oppashulp’) organises sitting services by volunteers during the day or at night. The facility sends a volunteer to people’s homes to keep them company or to give them a sense of security (because of their presence) and some basic care. Sitting services by volunteers are complementary to the professional help and to the help provided by informal carers. Sitting services are oriented towards a very heterogeneous public and are in that respect not bound to

ICT PSP Apollon

135

Final Version

Apollon – Deliverable 2.4 any limitations. A facility for sitting services can demarcate very specific target groups within its own operation, such as chronically ill people or disabled people.

More information about the facilities for sitting services: http://www.zorg-engezondheid.be/adressen_oppashulp/  Social services of the Health Insurance Funds

The social services of the health insurance fund (‘diensten maatschappelijk werk van het ziekenfonds’) provide help and services to home care users and their informal carers. Anyone can turn to these services with questions or problems relating to home care, care insurance, child allowance, retirement pays, etc.

More information about the social services of the health insurance funds: http://www.zorg-en-gezondheid.be/adressen_dmw/

 Cooperation initiatives in primary health care

A cooperation initiative in primary health care (‘samenwerkingsinitiatief eerstelijnszorg (SEL)’) is a cooperative venture between care providers. By working together these care providers aim to optimally improve the services and care they provide to their patients. They take initiatives to tailor their care provision to the needs of the patients in their region and conclude agreements in order to also align their services. A cooperation initiative in primary health care can also organise training for care providers and offers useful information. There are 15 SEL’s recognized by the Flemish Agency for Health and Care.

More information about the cooperation initiatives in primary health care: http://www.zorg-engezondheid.be/Zorgaanbod/Thuiszorg/Samenwerkingsinitiatieveneerstelijnsgezondheidszorg-(SEL)/

 Facilities for elderly care

It is the aim of the Flemish authorities to make sure that older people can live at home independently for as long as possible. However, there comes a time when this is no longer an option. In this case, the elderly person can turn to a residential elderly care facility. This is a facility where an elderly person can stay as a resident on

ICT PSP Apollon

136

Final Version

Apollon – Deliverable 2.4 either a temporary or a permanent basis. In other words, this facility becomes the new home of this elderly person. The Flemish Agency for Care and Health programmes and recognises several types of elderly care facilities: • Residential care centres • Rest and nursing homes • Service flats • Day care centres • Short stay centres • Recovery centres More information about the facilities for elderly care: http://www.zorg-engezondheid.be/Zorgaanbod/Residentiële-ouderenzorg/  Preventive health care providers

Logo’s Vigez Expertisecentrum Valpreventie Vlaanderen vzw

ICT PSP Apollon

137

Final Version

Apollon – Deliverable 2.4

Annex 2 health insurers in Belgium Belgium has a system of compulsory health insurance, which is managed by the National Institute for Health and Disability Insurance (NHDI-RIZIV-INAMI). The NHDI allocates a prospective budget to the sickness funds to finance the health care costs of their clients. Membership of a sickness fund - which are non-profit-making organizations - is compulsory. All individuals entitled to health insurance must join or register with a sickness fund or mutuality: either one of the six national associations of sickness funds (Christian Mutuality’s, Socialist Mutuality’s, Independent Mutuality’s, Liberal Mutuality’s, Neutral Mutuality’s or the Health Insurance Fund of the Belgian railway company) or a regional service of the public Auxiliary Fund for Sickness and Disability Insurance, which is a neutral public body intended for those patients who do not want to affiliate themselves with any of these groups.

Patients can buy supplementary insurance. Given that for profit insurers cannot enter the market for compulsory insurance, traditional sickness funds have huge informational and scale advantages, and more than 90% of their members buy some form of supplementary insurance from them. Therefore, the private insurance market in supplementary health insurance has remained limited and private insurers focus on the higher-income market segment.

Christian Mutuality's Public Auxiliary Fund for Sickness and Disability Insurance

Private health insurance company's Health Insurance Fund of the Belgian Railway Company

Socialist Mutuality's

National Institute for Health and Disability Insurance

Independent Mutuality's

Liberal Mutuality's Neutral Mutuality's

Figure 51 the Belgian Health Insurers

Annex 3 The health care system in Finland

ICT PSP Apollon

138

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 Health care in Finland consists of a highly decentralized, three-level publicly funded health care system and a much smaller private health care sector.

Although the Ministry of Social Affairs and Health has the highest decision making authority, the municipalities (local governments) are responsible in providing health care to their residents.

The Government decides on general national strategies and priorities and proposes bills to be discussed by the parliament. Health care policy is primarily the field of Ministry of Social Affairs and Health. The Ministry also directs and guides the development and policies of social protection, social welfare and health care. Due to the decentralized public administration, municipalities decide themselves how the local services are provided. Every municipality has a responsibility to offer health care services to their residents and it is usually provided municipal health care centers.

Primary care is obtained from the health care centers employing general practitioners and nurses that provide most day-to-day medical services. The general practitioners are also gatekeepers to the more specialized services in the secondary and tertiary care sectors, as a referral from primary care provider is necessary to receive care on the secondary and tertiary levels.

Secondary care is provided by the municipalities through district hospitals where more specialist care is available. Secondary care is provided by regional hospitals. Finland also has a network of five university teaching hospitals which makes up the tertiary level. These contain the most advanced medical equipment and facilities in the country. These are funded by the municipalities, but national government meets the cost of medical training.

Health care policy is primarily the field of Ministry of Social Affairs and Health.

The Ministry also directs and guides the development and policies of social protection, social welfare and health care. Due to the decentralized public administration, municipalities decide themselves how the local services are provided. Every municipality has a responsibility to offer health care services to their residents and it is usually provided in municipal health care centers.

The health care system receives funding from two sources. Municipal financing is based on taxes and is used to provide primary health care services. They also have a right to collect user fees, and receive state subsidies if their tax levy is not adequate for providing the public services required, based on the demographic factors on their area. Municipalities fund the health centers on the primary care level and regional hospitals on secondary care level. As municipalities are both the providers and purchasers of the health services it does not encourage for cost-efficiency. National Health Insurance (NHI) is based on compulsory fees and it is used to fund private health care, occupational health care, outpatient drugs and sickness allowance. Regional and university hospitals are financed by federations of participating municipalities.

Due to the comprehensive public sector, private health care sector is relatively small. Between 3-4 % of in-patient care is provided by the private health care ICT PSP Apollon

139

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 system. Physiotherapy, dentistry and occupational health services are the most often used health services on the private sector.

Each municipality organises services independently, which means, for example, that they are responsible for organising home care, housing services, institutional care and support for informal care. The way that services are organised may vary (for example municipalities can provide services independently themselves, they can organise/provide services together with another municipality, or they can provide a voucher to service users so they can buy services from a private service provider). The costs of the services provided by municipalities for their clients are determined by their income. Financial support is dependent on the municipalityâ&#x20AC;&#x2122;s age structure and the size of its population.

The statutory National Health Insurance (NHI) scheme covers all Finnish residents, and it is run by the Social Insurance Institution (SII) through approximately about 260 local offices all over the country. The responsibilities of this institute include coverage of some family benefits, National Health Insurance, rehabilitation, basic unemployment security, housing benefits, financial aid for students and state-guaranteed pensions. The NHI system offers varying levels of reimbursement for outpatient drugs, care from private providers, transport costs to health care facilities, sickness and maternity leave allowances, and some rehabilitation services.

Additional voluntary health insurance has a very marginal role in the Finnish health care system and is mainly used to supplement the reimbursement rate of NHI.

ICT PSP Apollon

140

Final Version

Apollon – Deliverable 2.4

Annex 4 The healthcare system in Spain-Andalusia Healthcare in Spain is managed at the regional level so the discussion that follows focuses on the specific regional case of Andalusia (where the pilot has taken place) but the model is extensible to any other part of Spain.

Healthcare in Spain uses the single-payer single-provider model. Almost all care provision is done by public entity with no copayments (except for drugs), deductibles or other forms of out-of-pocket spending by the users.

In the Andalusian case, the main provider is the Andalusian Health Service (SAS). SAS comprises both the primary care network and the specialized care provided in hospitals and other facilities. SAS has around 80 thousand employees, more than 1500 primary care centers and 43 hospitals.

There a few other public entities, much smaller, that also provide healthcare services (same ones as SAS) but function independently of SAS. These are called Public Health Agencies: • • • •

Agencia Sanitaria Alto Guadalquivir Agencia Sanitaria Bajo Guadalquivir Agencia Pública Empresarial Sanitaria Costa del Sol Agencia Sanitaria Poniente

There’s also a public entity for emergencies (Empresa Pública de Emergencias Sanitarias, EPES).

These public entities provide healthcare services for the whole region, a population of 8.4million.

In addition to this public infrastructure, anyone can purchase private health insurance.

Private insurance plays a small but growing role in the Andalusian healthcare ecosystem in two different ways: • •

Contract work for the public system (diagnostic imaging, clinical analysis, batch work for reducing waiting lists…)

Direct services to customers.

The private model follows the traditional separation of insurers and care providers, with most insurance companies covering almost all of the care providers.

ICT PSP Apollon

141

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 A very large share of the customers of these private insurers are civil servants. Civil servants in Spain, rather paradoxically for a country that relies so heavily on a fully public model for healthcare provision, get private insurance as a job benefit.

Private providers are generally small practices for specialized ambulatory care and private hospitals (usually companies owning a network of hospitals throughout the whole country). The presence of private providers for primary care is marginal. Almost all private care is specialties. In fact, most private insurance customers cite easy access to specialists as the main reason for purchasing the service.

Regarding elderly care, the landscape is more mixed: thereâ&#x20AC;&#x2122;s a big network of publicly owned elderly residences but this network is clearly not sized to cover the whole population that needs the services. So the regional government subsidizes the services in an even wider network of certified private elderly residences. In addition to this public/private regional network there are also fully private (i.e. not subsidized) residences.

ICT PSP Apollon

142

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4

Annex 5 Short overview of Dutch healthcare Healthcare in the Netherlands can be divided in three echelons: 1. Somatic and mental health care 2. 'cure' (short term) 3. 'care' (long term).

1) Somatic and mental health care.

Being referenced by a member of the first echelon is mandatory for access to the second and third echelon. The first echelon is done by home doctors (Huisartsen), comparable to general practitioner.

2) 'cure' (short term) For all regular (short-term) medical treatment, there is a system of obligatory health insurance, with private health insurance companies. These insurance companies are obliged to provide a package with a defined set of insured treatments. This insurance covers 41% of all health care expenses.

3)â&#x20AC;&#x2DC;care' (long term).

Long-term treatments, especially those that involve semi-permanent hospitalization, and also disability costs such as wheelchairs, are covered by a state-controlled mandatory insurance. This is laid down in the Algemene Wet Bijzondere Ziektekosten ("General Law on Exceptional Healthcare Costs") which first came into effect in 1968. In 2009 this insurance covered 27% of all health care expenses.

Other sources of health care payment are taxes (14%), out of pocket payments (9%), additional optional health insurance packages (4%) and a range of other sources (4%).Affordability is guaranteed through a system of income-related allowances and individual and employer-paid income-related premiums Dutch Healthcare Insurance Healthcare in the Netherlands is financed by a dual system that came into effect in January 2006. Every person living in the Netherlands is legally obliged to take out healthcare insurance. The insurance must provide standard cover including, for example, the cost of consulting a general practitioner, undergoing a test in a hospital or buying medication at a pharmacy.

Private health insurance companies are obliged to offer a core universal insurance package for health care at a fixed price for all, whether young or old, healthy or sick.

Everyone over 18 pays a flat-rate premium for the standard insurance package. This premium can vary from one company to another. Children under 18 do not pay premiums for health insurance cover. Instead, the state pays a contribution to the insurance company.

ICT PSP Apollon

143

Final Version

Apollon – Deliverable 2.4 Employees also pay an income-related contribution towards health insurance costs, but this is reimbursed by their employers. Employees pay tax on the amount reimbursed.

Health insurance companies are legally obliged to accept anyone who applies for a standard insurance package and charge all policyholders the same premium. Insurance companies are not allowed to charge the elderly or the sick higher premiums.

Equalising risks The health insurance system in the Netherlands is a system based on the principle of social solidarity, which is administered by private insurance companies. The government wants to make sure companies do not reject ‘expensive’ clients such as the elderly and people with chronic health problems. All insurance companies receive compensation for the additional costs that insuring people with a high health risk involves. This is called risk adjustment. As a result of this policy, people with frequent health problems do not need to pay more than others for their health insurance.

A key feature of the Dutch system is that premiums may not be related to health status or age. Risk variances between private health insurance companies due to the different risks presented by individual policy holders are compensated through risk equalization and a common risk pool. Funding for all short-term health care is 50% from employers, 45% from the insured person and 5% by the government. Children under 18 are covered for free. Those on low incomes receive compensation to help them pay their insurance. Premiums paid by the insured are about 100 € per month (about US$127 in Aug. 2010 and in 2012 €150 or US$196,) with variation of about 5% between the various competing insurers, and deductible a year €220 US$288.

From 1941 to 2006, there were separate public and private systems of short-term health insurance. The public insurance system was implemented by non-profit health funds, and financed by premiums taken directly out of the wages (together with income taxes). Everyone earning less than a certain threshold qualified for the public insurance system. However, anyone with income over that threshold was obliged to have private insurance instead.

Health insurance cover The healthcare insurance cover must include the standard package. This is the minimum legal requirement.

Standard package By law everyone must take out an insurance policy for the standard package, which includes the following items: • •

medical care, including care provided by general practitioners, medical specialists and obstetricians; hospital treatment;

ICT PSP Apollon

144

Final Version

Apollon – Deliverable 2.4 • • • • •

medication; dental care up to the age of 18; postnatal care; limited physiotherapy, exercise therapy, speech therapy, occupational therapy and dietary advice help to stop smoking.

Besides the standard package, you may opt to take out additional insurance to cover, for example, more extensive physiotherapy or the cost of dental care for yourself or members of your family who are over 18.

References: Quoted sources: 1)Wikipedia.org/Healthcare_in_the_Netherlands 2) Government.nl/ministries/vws 3) Centraal Bureau voor de Statistiek: http://statline.cbs.nl/

ICT PSP Apollon

145

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 Annex 6 results ADL pilot

In The Netherlands there are 10 houses equipped with the ADL system. This is done in two waves of 5 people for a period of 4 months each.

Waves 2 Months Elderly

Family 15 User E1 E2

4

10 Elderly home

Days of use Physicaly Service/day Login/day 125 121

E3 113 to daycare

Bad

Good 141

Average

Caregiver

Mentaly Note

Sensors/day Movements/day

271

1,5

5

Good 224

Good Forgetful

0,8 17 26

E4 110 Bad Dementia 111 9 every morning a nurse gets her out of bed E5 E6

102 109

E7 103 to daycare E8

101

E10

88

E9 96 caregives

Average

Good Good 345

18

Bad

100

Good Forgetful

ICT PSP Apollon

Dementia

Average Average

mental + login

caregiver is

Forgetful

178

Forgetful

Good 246

249 2,1 11 8

177 16

0,8 2,0

0,3

2 caregives

1,4

2,3

Goes to daycare,

7

0,2 1,8 1,4

18

1,4

average: phys + senors

Bad

100-150

Good 250-350

1,6 1,2

2 caregives, Goes 1,3

2 caregives 0,6

2 caregives, Goes

2,0

1,4

2,7

1,1

Goes to daycare

Good 0,2-1 Bad

2

average:

1,5-3,5

Amount of Service messages + logins: depends on how worried the

146

Final Version

Apollon â&#x20AC;&#x201C; Deliverable 2.4 If there are two caregivers, only one really uses the system

In Spain there are 15 houses equipped with the ADL system. This is done in two waves of 5 people for a period of 2 months each.

Waves 3 Months Elderly

Family 21 User

2

15 Elderly home

Days of use Physicaly Service/day Login/day 04-09-11 / 04-11-11

Mentaly Note

Caregiver

Sensors/day Movements/day

U1

61

Good Good 295

32

0,8

0,7

U4

8

Bad

17

0,5

2,2

U2 U3

U5

61 61

61

Average

Good 380

Good Good 117 Good 138

Good Good 106

07-11-11 / 23-12-11

0

12

95

0,5

0,6

0,6 0,9

1,9

1,1

2 caregivers

User left early

U6

46

Average

Good 534

51

0,8

2,3

2 caregivers

U9

46

Average

Good 525

106

0,7

1,4

3 caregivers

U7 U8

U10 U11

U12 U13 U14 U15

46 46 46

Good Good 90

11

Bad

117

Good Good 345 Forgetful

27-12-11 / 17-02-12 52

52 52 52 52

ICT PSP Apollon

Bad

Forgetful

Good Good 135 Average Average Average

67

578 14

Good 447 Good 510 Good 97

0,8 1,0 9

67

0,6 81

100 10 147

0,9 2

0,7 0,8

2,4 0,8 0,6 0,6

2 caregivers 1,1 0,6

2,1 1

0,8

2 caregivers

Final Version