Keywords

1 Introduction

Recent studies in the field of aging indicate that the seniors population worldwide is constantly growing [1,2,3]. In Europe, elderly population already represents 24% of the population (175 millions of persons), in contrast to 16% of youngsters (117 millions) [3]. While it is expected that the general Europe’s populace decreases over the years, current trends indicates that the quantity of seniors will reach rates of 27.2% of the populace by 2050 [4].

In the well-being and aging context, a collaborative Elderly Care Ecosystem (ECE), in line with the notion of a Collaborative Business Ecosystem, “has the potential to provide an environment where personalized services might increase customer satisfaction, and give service providers access to new opportunities, share costs and risks, and strengthen their business” [5]. In this context, Collaborative Networks are the cornerstone of collaboration initiatives among service providers. To accomplish these objectives, composition and rating of care and assistance services should meet particular needs, since customer care needs can be attended in distinct forms, considering various providers. This paper proposes a method to address this need.

The remainder of this article is organized as follows: the Elderly Care Ecosystem is introduced in Sect. 2. The Service Composition and Personalization Environment (SCoPE) method is also briefly mentioned. Section 3 introduces the ECE evolution system represented by the Service Evolution (SEvol) method. The ECE processes are described in Sect. 4. Finally, the conclusions are presented in Sect. 5.

2 Elderly Care Ecosystem - ECE

In general, a number of technologies has been employed to support organizations to work together better. The ubiquitous use of open distributed systems, such as internet-based systems, enables efficient distributed businesses process, faster time to market, and practical development through global economy [3]. In dynamic environments, such as found in health services, organizations are constantly comfronted to efficiently collaborate with other enterprises and compose personalized offers without losing quality and competitiveness.

In this context, we can resort to the concept of collaborative network (CN) which is defined as “an alliance constituted of a variety of entities (e.g. organizations and people) that are largely autonomous, geographically distributed, and heterogeneous in terms of their operating environment, culture, social capital and goals, but that collaborate to better achieve common or compatible goals, and whose interactions are supported by a computer network” [6].

A particularly relevant kind of CN is a Business Ecosystem (BE). A BE can be identified as a “long-term strategic alliance which tries to preserve local specificities, tradition, culture, and frequently benefit from local government incentives, involving a complex interplay of collaboration and competition around producers, consumers, regulators, and support entities” [7, 8].

One specific example of BE is given by the term Digital Business Ecosystem [3], which is also inspired on biological ecosystems, but with a stronger emphasis on the perspective of technological support. Furthermore, the term Collaborative Business Ecosystem (CBE) was introduced to emphasize the “collaborative environment” perspective [9,10,11]. The CBE is based on Collaborative Networks discipline and supports enterprises with collaborative tools to assist on the mitigation of organizations’ weaknesses while strengthen their know-how. As a result, organizations offering composite (integrated) care services in the ECE is expected to leverage their competitive advantage to customer agreement.

Our concept of Elderly Care Ecosystem (ECE) represents a particular case of a CBE. It includes various elements of a collaborative environment (administration, broker, virtual organization, planner, and coordinator), and specific elements that characterize it as an “Elderly Care Collaborative Network”, specifically the customers (seniors), customer’s request and requirements, customer’s care needs, ECE services, and ECE service providers, including others [11,12,13]. Figure 1 presents the ECE environment domain diagram highlighting four ECE subsystems: ECE Manager System, ECE Information System, ECE Personalization System, and ECE Evolution System, and the three phases involved in the operationalization of ECE: Preparation phase, Execution phase, and Monitoring phase.

Fig. 1.
figure 1

ECE environment domain diagram

Full size image

The Preparation phase corresponds to the creation of ECE and definition of its rules and functionalities within a collaborative environment. It involves (i) representing the main body of information and knowledge, (ii) the target audience identification, the considered stakeholders, specifically partners in the several areas (entity of support, entity of regulation, private institutions, governmental companies, freelancing professionals, caregivers, etc.) which are members of ECE, (iii) human and ICT resources, (iv) business and management rules; and (v) characterizing the available services. Based on a number of templates this phase involves creating the taxonomy of care need goals, identifying the service provider profile, service profile, and customer profile. The main subsystems responsible for the Preparation phase are the ECE Manager System (ECEMS) and the ECE Information System (ECEIS). \( {\text{ECE}}_{\text{MS}} \) is consolidated through the pillar of collaborative networks and the ECEIS is more detailed in the next sections in the current chapter.

The Execution phase relates to the process of composition and personalization of services, including the ranking of the offered pairs (services and demand (customer care needs)). The main actuator subsystem at this stage is the ECE Personalization System (ECEPS) which involves the Service Composition and Personalization Environment (SCoPE method). This method comprises three steps: scope filtering, service adherence calculation, and service composition and ranking.

The Service Composition and Personalization Environment (SCoPE) was proposed in our previous work [5]. The method is composed of three main stages: (1) Scope Filtering – responsible for matching and filtering service and providers considering the care needs taxonomy, (2) Adherence Calculation – responsible for the outcomes of the first rating of services and providers considering their fitness for a specific customer, and (3) Service Composition and Ranking – responsible for recommending a solution list of providers. Figure 2 presents the SCoPE overview.

Fig. 2.
figure 2

SCoPE method overview

Full size image

The Monitoring phase implements the ECE Evolution System (ECEEV) that supports the service evolution and monitoring in the ECE Service Personalization (ECEPS) environment. ECEEV supports the Service Evolution (SEvol) method. Considering the dynamic environment and stages of life of the elderly, the ECE broker analyses the situation and adapts the services to fit each new context. In this way, SEvol evolves an existing care solution to cope with the new customer’s life stage (e.g. handling new customer inputs, new or obsolete care needs, technological issues, new business strategies of service providers, etc.). The detailed process of the self-adaptive system approach for service evolution into ECE (ECEEV and the SEvol method) is presented in Sect. 3.

3 ECE Evolution System

3.1 Evolutionary and Adaptive Systems

Adaptive and self-adaptive systems are a broad area of research with significant recent advances [14, 15]. These systems are characterized by having the capability of modifying their behavior and/or structure in response to their perception of the context and the system itself, and their requirements [16]. In summary, an adaptive system is “required to monitor itself and its context, detect significant changes, decide how to react, and act to execute such decisions” [14, 15].

The critical fact in a self-adaptive system is that its life-cycle should not be interrupted after its development and initial set up. Similarly, service operation should continue after deployment while evaluating the system and responding to changes at all time. In this sense, self-adaptive systems are realized as closed-loop systems with feedback loop [14]. During the adaptive process, it is possible to perform (if necessary) a human-in-the-loop action and the process continues after customer’s feedback. In this situation, the adaptive system has a semi-dynamic adaptation.

Semi-dynamic adaptation is classified into two main paradigms that determine the range of possible states a system considers during the decision process [17, 18]: dynamic behavior adaptation, and dynamic reconfiguration.

In the case of dynamic behavior adaptation a system recognizes new environment conditions not envisioned during development and then control and order is emergent rather than predetermined. In the case of dynamic reconfiguration it encompasses possible variants of behavior that are somehow predefined before execution. During execution, current state, environment, and context are evaluated, and the most appropriate behavior variant is selected.

Some architecture-based adaptation frameworks have been proposed and developed over the years. They represent either academic or industry initiatives to address issues on the self-* properties and the adaptation process itself [15, 19]. Developing adaptive technologies and frameworks is beyond the scope of this work, hence existing adaptive approaches are considered to support our approach.

The proposed evolution system is based on the MAPE-K control loop structure [20, 21]. This control loop traditionally covers four elements: Monitor, Analyze, Plan and Execute. “Monitor” collects the details from the managed resources (e.g., sensors data, customer’s information, configuration property settings, etc.). The monitor function gathers information, filter it and aggregate it (besides normalizing) until detect a condition that requires analysis. “Analyze” function is responsible for complex data analysis and reasoning based on the conditions detected by monitoring phase. If some modification is necessary, a change request is invoked to the plan function. The “Plan” organizes the actions needed to achieve the target goals and creates (or selects) a process that will enact the modifications. Finally, “Execute” functions operationalize the modifications by executing the planned actions on managed resource. This is accomplished with the use of specific effectors.

3.2 SEvol Method

In the elderly care ecosystem domain, and for each new context change, the proposed ECE Evolution System analyses the situation (in collaboration with the relevant stakeholders) and adapts the service to fit that new context. In other words, the Service Evolution (SEvol) method supports the solution evolution to cope with the new life stage. Under this perspective, the notion of evolutionary service [22,23,24,25,26] means that the provided service is adapted to the senior’s needs, and to any changes that affect the senior’s life context.

Following MAPE-K, the SEvol method is based on a control loop composed of four main stages: (i) monitoring events that occur in the surrounding physical and social context (i.e., both context changes and messages exchanged between stakeholders); (ii) analyzing monitored data against solution requirements to identify need of adaptation; (iii) devising an evolution strategy that reconciles current solution with a new customer’s context; and (iv) enacting such strategy while minimizing disturbances caused by suggested solutions. These stages are identified in the i* rationale strategic model (see Fig. 3) that provides an intentional description of processes in terms of process elements and the rationales behind them [27].

Fig. 3.
figure 3

Adapted i* rationale strategic model for the evolution system loop in ECE

Full size image

The main actor is Evolution System (A-04 in Fig. 3) that is supported by additional elements of the model: Context sensor (A-01), Agent (A-02), and Contextual actuator (A-03). In more detail:

  • Context sensor (A-01) is seen as a computational entity (hardware and software) providing raw data about the elderly environment. For instance, a bracelet that determines the current location of the customer or other stakeholders (e.g., who deliver/execute the care service), the sensor that determines the temperature and humidity levels in specific places, the smart communicator’s automatic incoming/outgoing calls, etc.

  • Agent (A-02) represents each of the actors who need to be monitored to ensure that they deliver according to their role in the ecosystem and send feedback about their acts. These agents may represent a senior, her/his guardian or caregiver, the coordinator of the virtual organization, VO (who manages the care service delivery for this senior), a service provider (which is part of a VO), etc. Agents are linked to the Evolution System (A-04) through inputs provision to identify a new request or through choices made in the human interaction. For instance, a substitution of a resource may be solicited by a service provider.

  • Evolution System (A-04) provides the self-adaptation capabilities of our model. This actor is split into four sub-actors:

Sub-actor Monitor (A-05) receives the information from agents (Agent (A-02)) and sensors (Context Sensor (A-01)). The inputs from the agents can be of several origins, for instance, from the customer and his/her family and guardian, or from the ECE, mainly originated in the Virtual Organization (VO) coordination, ECE management, or service provider. The inputs from sensors represent data about the elderly environment, for instance, information about senior’s sleep analysis. Examples of outcomes are (i) the identified new care need, (ii) indication that a care need is no longer present, and (iii) indication that service changes the delivery parameters.

Sub-actor Analyzer (A-06) receives, from Monitor (A-05), information about the current elderly context living (New context (R-01) or New request (R-02)) and observes the pattern identifying the solution parameters that need to evolve.

Sub-actor Planner (A-07) selects evolution strategies to be adopted by the ECE policy manager (A-08), and ranks suggested solutions. The proposed solution evolution approach in ECE is based on (1) composition (or decomposition) of the current solution (Service addition (T-08) or Service removal (T-09)); (2) solution parameters change (Parameters adaptation (T-10)), for instance, delivery conditions; or (3) the change of the entity responsible for the care service delivery (Provider change (T-11)).

Sub-actor Executor (A-09) changes the behavior of the managed resource using effectors based on the actions recommended by the Planner (A-07). Notice that evolution should not be considered a new personalization since it does not seek the better possible results from scratch, but instead seeks a satisfactory solution with the least possible disturbance to the customer (that is already used to the specific characteristics of current solution).

More details about these four sub-actors are presented in the following subsections.

Sub-actor Monitor.

The Monitor’s (A-05) purpose is to identify relevant changes in the physical and social context, notifying the Analyzer actor (A-06). To collect inputs, the Monitor relies on context sensors and agents. Distinct tasks are needed to carry out the Monitor’s goal:

The task Information normalizer (T-01) initiates the monitoring function, taking its input from sensors or agents. The collected data and provided inputs are normalized to a “common language” that expresses the information on a context model (see Fig. 4).

Fig. 4.
figure 4

Overview of Information normalizer task

Full size image

The Collects data (G-01) and Provides inputs (G-02) are required by the Monitor’s tasks: Interaction monitor (T-02) and Context monitor (T-03).

The Interaction monitor (T-02) processes the status of existing non-standard data and exposes it through New request (R-02). For instance, a service provider will no longer deliver a specific service, or the customer wants to lower the price of a solution.

The Context monitor (T-03) computes information related to context and establishes New context (R-01). For example, if the customer has a medical appointment and her/his location is not moving, this information is sent (He/she did visit the doctor), or he/she is five days without leaving home, not participating in routine meetings (indicating signs of isolation, a possible new care need.)

Figure 4 sketches how the Information normalizer (T-01) works. Some inputs are sent in different formats: an XML file from the smart t-shirt, binary raw data from the door, CSV (comma-separated values) data from the thermometer, change of request from the customer activating (or disabling) care needs, customer is changing the constraints, and a service provider removing a limitation or adding an application suggestion.

Normalization demands the definition of a translation plan for each raw data format. If the task sources provide data in standard formats (e.g., XML file from the smart t-shirt), transformation schemes can be defined using a transformation language (e.g., XSLT – eXtensible Stylesheet Language Transformation).

If the house entrance door is closed (e.g. door.status = closed) and an event such as open(door, time i) happens, the Context Monitor (T-03) converts these data in terms of a shared context environment changing the status of the entrance door to open (door.status = open) – representing a New context (R-01): “door1.opened”. A the other hand, if the customer identifies a new need (e.g. need of transportation), the Iteration monitor (T-02) processes events related to context and exposes this requirement - representing a New request (R-02): “node35.active = transportation”.

Sub-actor Analyzer.

Sub-actor Analyzer (A-06) is responsible for checking current information about the Evolution System (A-04) collected by the Monitor.

The role of requirements to the Customer network analysis (T-04) is to specify the goals that should (or should not) be achieved by certain agents, the plans these agents can execute, and the domain assumptions that must not be violated. In this sense, the more detailed requirements model is the more accurate diagnosis will be. Moreover, agents’ granularity is constrained by pragmatic and technological issues. Identifying if the senior is lying on the bed for a long time is trivially gauged (e.g. with the use of pressure sensors), while effectively identifying if the senior is taking the medicine according to the current prescription is more complex.

The goal Patterns discovery (G-04) identifies and sets patterns of something routine that was not previously declared. It can declare patterns from the provider or stakeholders (sensors, caregivers, etc.). The task Evolution approach identification (T-05) observes the patterns of customer and indicates evolution parameters according to their relevance level, and provides the resource Evolution parameters (R-03) to sub-actor Planner (A-07).

Sub-actor Planner.

Planner (A-07) analyses Evolution parameters (R-03) selecting the evolution strategies to this context serving as a system interface with ECE policy manager (A-07) that handles policies defined by ECE managers. Evolution strategy selector (T-06) receives the Strategies (R-04) from ECE policy manager (A-07) and prioritizes these solutions considering the ECE policies and goals (subtask Prioritize strategies (T-07)). The suggested strategies for solution evolution are based on the following tasks: Service addition (T-08), Service removal (T-09), Parameters adaptation (T-10), and Provider Change (T-11). In the end, a resource Suggested solutions (R-05) is sent to the sub-actor Executor (A-09).

In our work, the evolution (or adaptation) is mainly based on direct inputs of customer. We consider as primary inputs to the evolution process: (a) the identified new care need, (b) identification that a care need is no longer present, or (c) identification that service changes the delivery conditions.

The proposed service evolution strategy in ECE is based on composition (or decomposition in case of service removal) of the current solution or the parameter change of delivery conditions. For each primary input, the detailed strategy is presented below (more details in [25]).

  • Situation (a): adding a care need x. The newly added care need is covered by current solution of the customer; therefore, adding a new care need implies the adaptation of the integrated {service, provider} pairs. It is possible to classify this adaptation into two categories: (a1) Identifying (in the current solution) a {service, provider} pair that covers the new care need (the solution is not changed). (a2) Adding a new {service, provider} pair that covers the new care need. So the process should identify if the current solution satisfies the new care need. If so, the process ends. Otherwise, the service and provider fragments which cover the new care need x are identified in order to extend the current solution (based on the adherence level resulting from SCoPE method).

  • Situation (b): removal of a care need x. This removal should not affect the current solution for the other care needs. So, two cases are considered: (b1) Removal of {service, provider} pair that covers the x care need (if this pair does not cover any other need). (b2) Change of {service, provider} pair that jointly covers x and other care needs (for instance a care need y). The immediate removal of a {service, provider} pair fragment (without prejudice to current solution) can only be done if it is exclusively attending the x care need. In this situation (b1), the {service, provider} pair fragment is eliminated along with the obsolete care need, and the calculation of the solution adherence is updated. Otherwise (b2), the {service, provider} pair fragment that is attending care needs x and y goes through a new process of calculating the adherence (SCoPE method) considering now only the care need that stays (y). The fragment can be updated if there is a better service adherence to y. The adherence is calculated by the SCoPE process. This process can be repeated when other care needs are also covered by the same fragment.

  • Situation (c): modifying parameters of a care need. In this situation, the customer’s care needs remain the same. However, specific requests are modified in ECE. For example, the customer usually requires a transportation service once a week, but for the next month, it will be twice a week (frequency parameter); the customer had a collective transportation service, but now she/he wants private transportation (service features parameter), etc. The evolution plan to change a care need parameter involves two stages: (c1) Identify the parameter which should be changed checking if the new value is available for the current solution, (c2) Find a {service, provider} pair available that attends the new parameter.

Sub-actor Executor.

The sub-actor Executor (A-09) executes the action and the solution is adapted according of new requirements. The task Reaction strategy planner (T-12) calculates the rating of the evolutionary solution (task Solution rating (T-13)) and identifies the disturbance in relation to the old solution (task Disturbance identification(T-14)). In the next step, the human-in-the-loop phase is started and the ECE broker and the customer confirm (or decline) the new proposed solution (task Human interaction (T-15)), and the solution is updated (task Solution update (T-16)).

4 ECE Processes

As previously mentioned in Sect. 2, the ECE environment supports three main processes associated to care services: Preparation, Execution and Monitoring, and uses four environments: ECE Information System and ECE Manager System (briefly presented Sect. 2), ECE Personalization System and ECE Evolution System (presented in the Sect. 3).

To demonstrate the integration of environments and their roles step by step a workflow diagram is presented in Fig. 5. This diagram illustrates the main process flow split in five lanes (ECE Manager System, Customer, Service Provider, ECE Personalization System and ECE Evolution System). A brief description of each process of Fig. 5 is presented in the Table 1.

Fig. 5.
figure 5

ECE workflow diagram divided into five lanes

Full size image
Table 1. Brief description of each sub-process of Fig. 5
Full size table

To illustrate the applicability of the proposed ECE framework, Table 2 presents a summary of a practical application scenario relating the main ECE process.

Table 2. ECE process in a practical application scenario
Full size table

5 Conclusions

In this paper, we present a view about the influence of evolutionary and adaptive systems identifying the MAPE-k control loop structure. We propose a service evolution method (SEvol) to support the adaptation process (evolution) of current customer’s solution to new requests.

Following MAPE-K, the SEvol method is based on a control loop composed of four main stages: (Monitor) monitoring events that occur in the surrounding physical and social context; (Analyzer) analyzing monitored data against solution requirements to identify need of adaptation; (Planner) devising an evolution strategy that reconciles current solution with a new customer’s context; and (Executor) enacting such strategy while minimizing disturbances caused by suggested solutions. The K corresponds to the current customer’s solution. Providing an intentional description of processes in terms of process elements and the rationales behind them, the Evolution System was explained through an i* rationale strategic model. In the end, a workflow diagram is presented considering the main processes of ECE, demonstrating the roles of the ECE environments and the main stakeholders, separated in the three stages of: preparation, execution and monitoring. In addition, a practical application scenario is presented in the main ECE process to evaluate our approach. This proposal is intended to provide an adaptive system that can work well with an ECE framework to service personalization and evolution.

Ongoing developments include the assessment of the proposed method within a real elderly care ecosystem.