Keywords

1 Introduction

Europe is undergoing a demographic shift where the rising population of elderly is straining healthcare systems and institutions across Europe. There are more than 75 million people above 65 years of age living in Europe [1], and it is projected, that by 2060 the total number of people at 65+ will constitute up to 35% of the European Union’s population [2]. With old age comes increased morbidity and increased healthcare expenditures [1, 2]. European countries have in the last decades felt an increasing financial pressure due to chronic disease epidemics including: cardiovascular disease (CVD), cancer, diabetes, chronic obstructive lung disease (COPD), and chronic kidney disease (CKD), musculoskeletal diseases, and dementia. Already, chronic diseases affect more than 80% of people aged 65+ in most of the developed world, and is causing up to 90% of all deaths in Europe, with numbers foreseen to rise further in the next two decades [3]. An estimated 80% of healthcare costs are spent on chronic diseases in Europe, corresponding to an estimated cost of more than EUR 700 billion in the European Union alone, estimated to increase further as incidence rates increases further in the coming years [3].

Ambient assisted living systems have been hailed as a part of the solution and continue to provide increasingly more advanced services aiming at increasing the efficiency and effectiveness of caregivers and promoting additional self-care and patient autonomy [4]. The European Commission has been a major proponent for supporting this change, including via the AAL programme, a research program focusing on AAL as the solution to the demographic shift, strongly supporting open data and science.

There are already countless relevant platforms and components available that may be reused in new AAL products and ecosystems [4]. Some of these are based on open source and/or open standards, supporting open data and open science. However, many relevant products which are popular in the AAL community, and used widely in AAL programme projects, are tied to a third-party cloud service, where data security cannot be ensured by the healthcare provider organization themselves, thus potentially violating the GDPR rules of private and public healthcare service provider organizations. As an example, FitBit activity trackers have been used in several AAL projects. FitBit devices feature a functional semi-open API, allowing AAL ecosystem IT architects to tap into activity data (steps, sleep, heart rate) using basic REST based communication protocols accessing Fitbit’s cloud services. However, systems based on Fitbit and similar services are often at the mercy of the product vendors (in this example, the US company Fitbit Ltd.), who can, at any time, and without warning, change their API or revoke access to the API altogether, leaving all systems using Fitbit devices vulnerable to future events outside of the control of the end-user organization. Same goes with Google Wear based devices using the Google Fit API, Apple wearables featuring the Apple HealthKit, and similar products from other vendors, including from Samsung and Huawei. What seems tempting and easy to adapt at first, can turn out to be a major problem in the future, during the implementation or operating phases, not only in terms of integration problems with changing API’s and security tokens, but also in conflict with regional & national data security & privacy regulations. For instance, the storage of certain types of health data outside of Europe is not legal according to GDPR regulations, and some organizations even require that all data are kept locally within the ensuing organization with full accountability and ownership of data. Arguably, it is thus highly relevant to ensure that components being selected for existing and new AAL ecosystems, are not relying on third party servers, where data, privacy, and ethical regulations cannot be guaranteed. Thus, this paper calls for policy and decision makers to require components to be transparent, and to make support for open API’s mandatory when designing new AAL systems and ecosystems.

The CARIOT+ Care Coach ecosystem presented in this paper is an example of an ecosystem consisting of individually independent components, that may be used either stand-alone or in combination with each other, as well as with third-party components. The CARIOT+ Care Coach ecosystem is based on work done in three AAL projects, the CAMI project, which developed a range of independent but mutually compatible ambient assisted living products and system components for supporting elderly with one or more chronic diseases, including the CAMINO telemedicine gateway (which was later developed into the CARIOT gateway product), and the HELP ME BRUSH and ORASTAR projects, which both have focus on supporting oral care, in the nursing home setting and the home care settings respectively.

The aim of this technical paper is to present the CARIOT+ Care Coach ecosystem for supporting open data and open science.

2 Methods

A study on end-user and technical design needs based on the synthesis of data from three AAL projects CAMI [5], HELP ME BRUSH [15], and ORASTAR [16] projects spanning four European countries, was performed. It involved mixed methods including workshops, interviews, field studies with observations at nursing homes, private homes, and hospitals, questionnaire studies with healthcare professionals: doctors, nurses, caregivers, dentists and dentists’ assistants, as well as patients and informal caregivers. This was combined with technical design considerations and discussions with legal representatives and decision makers. The synthesized collated findings from the end-user and technical design studies led to a range of research challenges being identified, which were later used to create formal requirements for building the CARIOT+ Care Coach ecosystem. The resulting individual components are presented in this technical paper in order to provide an overview for third party developers seeking to use the full ecosystem or components thereof, in order to support open science and reuse.

3 Results

In the following sections, the ensuing CARIOT+ Care Coach ecosystem is described including its individual components. It is important to note, that the components can work independently of each other, allowing for open innovation. Thus, both the CARIOT gateway, as well as the apps presented in the following: the BeSAFE smart phone and smart watch apps, the CAMINO user interface, the OpenTele clinician and patient apps, and the REDCap clinical database can all be used as part of other ecosystems relying on open API’s for integration, securing HIPAA and GDPR regulations are respected, and securing full control and transparency to the clinical partners, thus securing support for open data and open science. Next all user interface components can be replaced with new components, or they can get their data from other gateways and even become part of third-party ecosystems. Finally, the CARIOT gateway is not tied to any specific type of medico devices as long as they comply with the Bluetooth BLE (GATT) or Bluetooth ISO/IEEE 11073 PHD standard, although each device needs to be supported by relevant drivers. Likewise, the BeSAFE app can run on any Android based device (Google Wear for the BeSAFE Wear smart watch app).

We start with presenting the CAMINO Home Platform, which constitutes a major part of the CARIOT+ Care Coach ecosystem, originally developed as part of the CAMI project and later used for the HELP ME BRUSH & ORASTAR projects, as it enables the link from the home of the end-user with the rest of the ecosystem. A range of applications & devices are supported by the ecosystem, some of which will be presented.

3.1 The CAMINO Home Platform

The CAMINO Home Platform (Fig. 1) was jointly developed by the Danish company Aliviate and Aarhus University. It is conceptually based on the existing open-source project OpenCare and the Common Ambient Assisted Living Home Platform (CAALPH) developed as part of the CareStore project [6], and further modified to suit the CARIOT+ Care Coach ecosystem’s requirements. OpenCare has been used for more than 10,000 nursing home end-user touch screen solutions marketed by several commercial vendors utilizing alternative user interface and back-end server functionality.The CAMINO Home Platform consists of a core engine running in a.NET environment, either Windows.NET or Linux Mono, which controls the execution of a range of independent micro-services, running either as separate processes or services, or running in a virtual machine process, either as virtualized components, or in a full virtual machine. The CAMINO Home Platform core controls the lifecycle of all the services and delivers a graphical environment for launching graphical user interface services. The individual micro-services may be implemented in either.NET, Java, Python, native C or C++. This is possible through the use of remote procedure calls for inter-micro-service communication. The CAMINO platform supports the automated discovery of other devices deployed in the home setting, such as the CAMI, CAMINI and CARIOT gateways, using service discovery based on the Bonjour & Avahi technologies, based on the Zero Configuration standard. These allow for the automatic detection of other hardware nodes in the network, including for instance one or more CARIOT gateways deployed in the home, thus enabling them to discover each other and synchronize.

Below, we present a selection of the graphical user interface applications that are running as micro-services within the framework. First, the Home Screen application (shown in Fig. 2), which is the starting point of the interactive system, in the shape of a touch screen launch menu for all registered user interface applications installed in the ecosystem. It is also possible to activate applications automatically (e.g., from an incoming call), or if an event is triggered by a sensor, e.g., a fall detection device, which could launch an audio sound alert asking for the user to confirm that he or she has not fallen.

Next, the “Health application” (Fig. 3), which can present healthcare data from either a local event data storage, from either the CAMI Cloud, OpenTele or REDCap. In fact, due to its open design, any data source can be used. The “Health application” is adapted for these diverse data sources and can easily be modified to include third-party components.

The Robot Control Center app (Fig. 4), which provides control over installed robots in the home setting. This application requires manual installation and configuration of all service robots.

Besides these, the Appointment, Calendar and Task applications provide basic calendar and task display and management to the user, including reminder services. All of these applications integrate seamlessly into the CAMINO Ecosystem, but may also run as stand-alone applications, or as part of other ecosystems.

Fig. 1.
figure 1

The CARIOT+  CareCoach platform running on a touch screen device in the home of an end-user with the CAMINO user interface. The screen is an “always on device”, which allows the user easy access for launching apps and getting information. A pattern adapted by several commercial AAL vendors, and used in more than 10,000 deployments.

Full size image
Fig. 2.
figure 2

The “CAMINO home screen” application represents the starting point of the user interface (same user interface as shown in an end-user setting in Fig. 1). From here, all installed applications featuring a graphical user interface may be launched. They will run as micro-services using inter process communication.

Full size image
Fig. 3.
figure 3

The “Health” application also runs as a separate process acting as a micro-service. It can either communicate with local data services, or with cloud-based data stores. It can run stand-alone, or as part of the CAMINO platform & ecosystem, launched either from the home screen, or when a new measurement is received.

Full size image
Fig. 4.
figure 4

The Robot Control Center application is another example of a user interface application. It is used for basic starting and stopping of service robots, including vacuum cleaners. It can either run stand-alone or as part of the CAMINO Platform and ecosystem.

Full size image

3.2 CareCoach User Interface

The CareCoach User Interface is a basic version of the CAMINO user interface. It especially targets end-users who prefers or requires (e.g., due to cognitive impairment) a minimalistic user interface that is extremely easy to navigate and use. It operates using microservices and receives data configured for the user, and facilitates limited end-user interoperability. As shown in Fig. 5, the system can be used to sample the mood of the user when an occupancy detects the user arriving in the area every morning, which is useful in many AAL and telemedicine scenarios. As shown in Fig. 6, it can also be used to present relevant sensor data arriving, e.g., that a blood pressure was received. It can also include localized decision support, prompting a warning if a measurement is beyond normal. Finally, when no relevant info is shown, the screen can either turn black, or shift between a range of pictures previously uploaded by the end-user or by relatives (Fig. 7).

Fig. 5.
figure 5

A mood indicator in CareCoach

Full size image
Fig. 6.
figure 6

Receiving various medico data and providing relevant information.

Full size image
Fig. 7.
figure 7

The system turns into a wall picture viewer when not in use.

Full size image

3.3 The REDCap Platform

The REDCap platform (Fig. 8) is a “secure web application for building and managing online surveys and databases” [11]. REDCap can be used to collect “any type of data in any environment” specializing in healthcare data. It supports both “online and offline data capture for research studies and operations”, including having an HTTP-based REST API, which for example is used by the CARIOT gateway for reporting measurements. REDCap was originally developed by Vanderbilt University and since 2006 maintained by the REDCap consortium. REDCap is free to install and use on a research or clinical end-user organizations own server, it is however not open source, and the strict licensing rule implies, that only healthcare and research organizations are allowed to use it free of charge. Thus, REDCap is not useful for commercial projects not involving a clinical and/or a research partner. It is highly suited for supporting strict HIPAA and GDPR regulations, especially those concerning clinical projects, which have higher ethical and legal requirements than “wellbeing” projects.

Fig. 8.
figure 8

REDCap is a database with API & a web-based user interface. It is used to collect clinical research data. An important feature is that each member organization can install the server and database in their own hosting environment, & thus comply with HIPAA & GDPR rules, and any national, regional, and local restrictions.

Full size image

3.4 The OpenTele Platform

The OpenTele platform is a telemedicine ecosystem based on open-source technology [7, 8]. The 4S organization who is responsible for the further development of OpenTele defines it as: “a complete telemedical platform for handling patient-recorded outcome data and measurements from personal health devices. The platform comprises a server part and a tablet and/or smartphone app installed which is either provided to the patient or installed on the patient’s own device if possible. From the OpenTele app, the citizen can answer questionnaires, perform measurements, and via a video link communicate with the general practitioner or hospital staff. The server also features a web site where a clinician can login, manage, and communicate with patients, as well as review collected data” [7] as shown in Fig. 9.

OpenTele is both open source and component-based, and thus very adaptable and extendable for new applications [8]. It is built using the Java programming language for the server side, and HTML5 and JavaScript for the web clients (Fig. 9). The database is based on the popular MySQL database server, while a REST interface is provided for integration with third party systems using JSON (Java Script Object Notation) encoding [7]. Besides the OpenTele Android app for patients, a code library (named 4SDC) for integrating with a range of IEEE 11073 telemedicine medico devices has been developed [7, 8].

OpenTele has been deployed to more than 10,000 telemedicine patients and has been adopted by more than 20 organizations around the world, including private companies, hospitals, and care institutions [8]. OpenTele is in many ways unique in the sense that no other widely deployed open-source telemedicine system exists, where the source code can be downloaded and modified by any third-party company or research organization, thus being a proponent of open data, open science, and open innovation. It continues to be used for clinical applications, including with back-end integration to electronic patient record systems. OpenTele has also been adapted to become part of the CARIOT+ Care Coach ecosystem where it can be used both as backend web site for clinicians, but also as a patient user interface. Integration is achieved using OpenTele’s REST interface using the OpenTeleNet API, as an example of the open data approach of CARIOT+.

Fig. 9.
figure 9

The OpenTele open-source telemedicine platform has been used together with many patient types, including hypertensive patients, COPD patients, heart failure patients, diabetes patients, and pregnant women suffering from preeclampsia.

Full size image

3.5 The BeSAFE and BeSAFE Wear Apps

The BeSAFE app for smartphones and the BeSAFE Wear app for smart watches (Fig. 10) were developed by Aarhus University and Aarhus University Hospital for facilitating clinical telemedicine research into patient activity, rehabilitation, and fall detection where sensor fusion, combining environmental (ambient) sensors with wearable sensors were needed, and where it was not legal to use Fitbi, Google Fit, nor Apple HealthKit (or similar) cloud-based services. Thus, the BeSAFE apps provides basic activity tracking, including pedometer (based on Android’s step counter virtual sensor service), location tracking (BLE proximity), as well as fall detection. The BeSAFE apps can send data via either HTTP(S) REST or MQTT formatted using JSON following the HEUCOD recommendation, a tentative open standard for “Healthcare Equipment Usage and Context Data” systems [21].

The BeSAFE apps allows clinicians at Aarhus University Hospital to do independent research, sending data directly to a REDCap database. Both apps are open source, and can be adopted for third-party ecosystem and other scenarios of use.

Both BeSAFE apps are open source, and build on open-source software by James Montemagno. They are completely free of any bindings to for-profit companies, and can be used as a research platform.

Fig. 10.
figure 10

The BeSAFE smartwatch app (the three screen shots to the left) and the BeSAFE Wear app for Google Wear devices (to the right) are both open source, based on several research papers. Low-cost activity tracking, achieved through support for below EUR 150 smartphones and smartwatches, is especially useful in the AAL field. By using a fully open infrastructure, it is easy to combine services, e.g., a pedometer service for rehabilitation, with a fall detection service. BeSAFE can be used together with REDCap and/or OpenTele for storage, and with CAMINO, OpenTele and the CARIOT gateway to become part of a full telemedicine setup which can be useful for many patient types, including hypertensive patients, COPD patients, heart failure patients, diabetes patients, and pregnant women suffering from preeclampsia.

Full size image

3.6 The CARIOT Gateway

The CARIOT gateway (Fig. 11), is developed by the Danish IoT company Aliviate, Aarhus University, and the University of Minho, and brought to market by the Danish AAL service company Medica Connect as the CARIOT BRUSH product. However, it can be licensed by any third-party company looking for full control of a multipurpose gateway product with source code access. It enables non-internet connected healthcare and care devices such as blood pressure, saturation, and weight devices used for traditional telemedicine and telehealth applications to become internet-of-things (IoT) enabled [9]. This includes: support for the open source “the Things Network” IoT Cloud platform, as well as support for commercial IoT platforms such as Loriot.

This integration is achieved using a combination of 2G, 3G, 4G, LoraWAN, BLE, and/or WiFi communication channels, depending on the specific usage-scenario and the needs of the end-users. The widely used medico devices for telemedicine and telehealth are already supported, including IEEE 11073 PHD and BLE GATT based devices, and the CARIOT platform can easily be expanded with additional healthcare and acre devices as required.

Fig. 11.
figure 11

The CARIOT gateway is marketed by Danish company Medica Connect, but both hardware and software stacks can be licensed to third-parties. It is essentially a platform rather than just a gateway, and can both communicate with local medico and ambient sensor devices, store the data, provide end-user warnings and signaling (via light and sound interfaces), as well as perform long-range communicate using Lora, GSM (2G), 3G/4G/5G, and WiFi. The software stack is flexible, and besides Lora and IP communication, HTTP/HTTPS/REST/MQTT is supported out of the box to any end-point. Some models have support for ZigBee, while BLE and Bluetooth is fully supported. As shown on the illustration, we have used the gateway with toothbrushes, blood pressure and weight devices, as well as presence and occupancy sensors.

Full size image

Besides telehealth and telemedicine devices and services, the CARIOT gateway supports a range of telecare and personalized medicine devices and services. These include traditional telecare and ambient assisted living services such as fall detection and prevention, generalized support for tracking user activity-levels and activities of daily living using both wearables and ambient sensors. Furthermore, the CARIOT platform has support for interfacing with ZigBee sensors, and thus more than 3,000 different sensors.

The CARIOT gateway can in the CARIOT+ Care Coach ecosystem be substituted by other data capture gateways, including the CAMI gateway platform developed by the Swiss company Eclexsys, and the CAMINI gateway developed by Danish company Aliviate, both of which are running the open source AdCAMI service developed by Aliviate, for supporting telemedicine devices, such as blood pressure, oximeter, weight, temperature and more. Other commercial sensor gateways exist, including the Qualcomm 2Net gateway. However, the Qualcomm 2Net gateway relies on the use of closed silo cloud solutions, with a REST API providing access using a subscription-based business model.

The CARIOT gateway features seamless service discovery on WiFi networks, using the Bonjour and Avahi frameworks, as well as zero-configuration deployment when using LoraWAN or 4G. The Bonjour zero-configuration service means a CAMINO or OpenTele app can automatically detect the presence of a CARIOT gateway on the network, and allow for easy connection. Also, the CARIOT gateway can be detected via Lora presence or via a unique and proprietary IP-based MQTT discovery service.

The CARIOT gateway can be provided in an open-source version free for research use, but its foremost strength is, that it allows absolute control of which storage location and technology is preferred by the end-user organization, allowing for full HIPAA and GDPR flexibility. Any third-party system can integrate with the CARIOT gateway, where integration is possible using either Lora or IP-based protocols, including REST & MQTT.

3.7 CARIOT+ Care Coach Ecosystem Architecture

The CARIOT+ Care Coach ecosystem utilizes a microservice architecture [12] with a focus on open standards and open data connections. Microservice architectures is in widespread use both in industry and academia [13]. In the Microservice architectural style, a system is composed of independent and fine-grained services, each running in its own process, often in a distributed system setting, and communicating using lightweight protocols such as HTTP or MQTT [13, 14]. Microservices and microservice architectures are intended to be simple and focus on accomplishing one task well, while retaining the ability to work independently of each other (within practical limitations), which also implies that they can be reused for different purposes [14]. Also, due to their heterogeneity, each service can be built using the most appropriate technologies for the task, making it possible to combine different open source and commercial products into a single system. As an example, the CARIOT+ ecosystem uses both C, Python, Java, HTML5, and C#, running on both servers, PC’s, and embedded hardware. Furthermore, microservices natively support so called “continuous delivery” allowing frequent releases and fast feedback loops. As opposed to a Service-based architecture, where system vendors rely on third-party services, e.g., on a Fitbit cloud service, the Microservice architecture prescribes that the system owner has full control over all components in the system.

4 Discussion

The aim of this paper was to provide an overview of the various components identified during three AAL projects as useful for supporting an open ecosystem for ambient assisted living services for supporting open data and open science, and open innovation. The paper was made in order to inspire the AAL and other research communities and industry vendors to reuse existing frameworks when building new systems, including those presented in this paper, and to a higher degree rely on open standards-based micro-services using open and standardized communication protocols, rather than closed silo solutions. In addition, by sharing our findings, we hope to receive suggestions from the community on other third-party platforms that would be useful for expanding on the CARIOT+ Care Coach Ecosystem.

While there is naturally some amount of manual technical plumbing involved, the CARIOT+ Care Coach ecosystem is fairly easy to configure and deploy, both on a cloud server, on a private networked server, or even as an in-home-only system, providing ultimate privacy settings. However, the technical difficulties in bringing heterogenic platforms and technologies together should not be underestimated.

Thus, we will not argue against the need for large monolithic care applications and services for some use cases, but with the CARIOT+ Care Coach ecosystem, we have shown the way for a dynamic, flexible, and highly adaptable ecosystem that will allow for the integration with other systems through the use of open standards and the microservice architecture pattern. However, more work is needed, in terms of creating a true standards-based common inter-communication language for these services. Here, the HL7 FHIR standard [20] appears highly relevant to employ combined with the emerging HEUCOD recommendation [21]. However, HL7 FHIR is only slowly maturing into relevancy for the AAL sector, and more work is arguably needed before it becomes an effective tool for use within the AAL community.

Finally, we acknowledge the work of previous consortia to develop similar open ecosystem architectures for ambient assisted living, including the UniversAAL and the Reaal platforms [4, 10, 17,18,19]. The integration from CARIOT+ with these platforms has not yet been achieved due to a range of dependencies that we were not able to satisfy, and plain difficulties in running the open-source code provided by these frameworks. Thus, we would recommend for the redesign of these platforms, and any similar platforms, to be divided into smaller services as. microservices, which would allow easier reuse of the platforms as part of new ecosystems, and we would call for creating dedicated and low-cost hardware, such as sensor gateways, which will make it fast to start integration efforts. In addition, we call upon added standardization support in the field. While there are many standards for device integration and healthcare data integration, the CARIOT+ Care Coach ecosystem currently has to rely on industry standards including MQTT and HTTP to create an effective middleware. A tentative recommendation is being developed as part of the HEUCOD project, called the HEUCOD recommendation [21], which is currently supported by the CARIOT+ Care Coach ecosystem, but which need to be further disseminated and developed in order to attract proper industry interest.

5 Conclusion

This paper has provided an overview of the CARIOT+ Care Coach ecosystem. The paper presented the various components used, and detailed how they could be used together, either as part of the ecosystem or to help build other systems, or even become part of third-party ecosystems, completely independent of CARIOT+.

However, as argued in the paper, the main quality of the approach of the CARIOT+ Care Coach ecosystem lies in the extensive support for open science and open data, as the ecosystem does not rely on cloud services from third party vendors which could be in conflict with legal and ethical regulations and requirements in the partner country, but rather support REDCap and OpenTele, which combined represents some of the most used datastores for clinical research. Also, by ensuring full developer control of all components, including the interfaces, endpoints, and connection; projects using the CARIOT+ Care Coach ecosystem will not run the risk of sudden and unexpected breaking changes from a third-party vendor, nor the risk of breaching GDPR regulations.