A technical platform for environments for ageing--lessons learned from three field studies.

Inform Health Soc Care, 2014; 39(3–4): 272–293 ! Informa UK Ltd. ISSN: 1753-8157 print / 1753-8165 online DOI: 10.3109/17538157.2014.931853

A technical platform for environments for ageing – lessons learned from three field studies Marco Eichelberg,1 Felix Bu¨sching,2 Enno-Edzard Steen,3 Axel Helmer,1 Andreas Thiel,1 Andreas Hein,3 and Lars Wolf2 1

OFFIS – Institute for Information Technology, Oldenburg, Germany, Institute of Operating Systems and Computer Networks, Technische Universita¨t Braunschweig, Braunschweig, Germany, and 3 School of Medicine and Health Sciences, University of Oldenburg, Oldenburg, Germany 2

The Lower Saxony Research Network ‘‘Design of Environments for Ageing’’ (GAL) studied possible applications of assistive technology for enabling older adults to live longer and independent in their own home. As part of this work, a technical platform was developed as a common technical basis for all assistive systems in the project. This article presents an overview of the architecture and core functionality of the technical platform, which in the first generation was developed for use in a laboratory setting, and in a second generation was extended for use in the project’s field studies, i.e. prototype installations in end-users homes. The field studies’ primary objective was the evaluation of the assistive technologies, that were developed within the overall project. However, these studies also confirmed that the fundamental concept of the technical platform is valid, and the prototypes continuously worked 24 h a day for several months. However, there were some problems related to lack of infrastructure in the older adults’ homes and human factors such as inadvertent placement of objects across sensors’ field of view, acceptance problems due to aesthetical reasons or simply communication problems, which show that making complex technologies work for users with little technical experience is well possible, but requires a careful consideration of the complete service chain and related ‘‘soft factors’’. Keywords Ambient assisted living, field study, middleware, technical platform

INTRODUCTION The significant increase in life expectancy that progress in medical care, prevention and nutrition have enabled over the past few generations, combined with the reduction of birth rates that is apparent in most industrialised societies, together have caused a development that is described with the term ‘‘ageing society’’. As (1) points out, ‘‘the number of persons aged 60 years or older was estimated to be 629 million in 2002 and is projected to grow to almost 2 billion by 2050, at which time the population of older persons will be larger than the population of children (0–14 years) for the first time in human history’’. This development will cause frictions in our social systems, as fewer working people will have to finance pensions of an increasing number Correspondence: Marco Eichelberg, OFFIS – Institute for Information Technology, Escherweg 2, 26121, Oldenburg, Germany. E-mail: [email protected]

A technical platform for environments for ageing

of retired persons, and since the number of people in need of care will increase whereas the workforce available to satisfy these needs is shrinking. Furthermore, the increased mobility of workers required by modern industrial societies makes it more and more difficult to organise traditional family-based home care for the parents. On the other hand, the post-retirement phase of life is increasingly becoming an extended period of perhaps 20 or 30 years of relatively good health that can and needs to be actively shaped. New technologies may play an important role in coping with the challenges of an ageing society. As the European Commission points out, ‘‘the increased use of new technologies, such as telemedicine and personalised health care systems, available to senior citizens, their families and health care staff, could help to control health care expenditure and improve the well-being of citizens’’ (2). Research and development in this field has been one focal point of research over the past few years under the umbrella term ‘‘Ambient Assisted Living’’ (AAL). This article describes results from a large-scale interdisciplinary AAL project called the ‘‘Lower Saxony Research Network ‘Design of Environments for Ageing’ – Information and Communication Technologies for Promoting and Sustaining Quality of Life, Health and Self-sufficiency in the Second Half of Life’’ (in brief: ‘‘GAL’’), which was completed in September 2013 after 5 years of work. An outline of the overall project is given in (3).

PRIMARY OBJECTIVES While the focus of the technical work in the project was on the development of tools and algorithms for assistive systems addressing the four different application scenarios of the project (personal activity and household assistant, monitoring of preventive and rehabilitation sports, sensor-based activity determination, sensor-based fall prevention and fall recognition), it was clear from the outset that some cross-cutting themes needed to be addressed. One of these themes was the development of a common technical platform for environments for ageing. Despite all differences in user base, technologies and algorithms used, all four application scenarios have many requirements in common:

Different types of sensors and actuators (ambient, mobile and body-worn) need to be connected using a number of wired and wireless transmission techniques. Sensor data must be stored persistently for a certain period to enable the computation of trends. Storage should avoid proprietary, vendor-specific formats and instead store generic measurements in SI units. Software modules that process sensor data and derive trends, recommendations (decision support) or raise alarms need an execution environment. The system needs to be able to interact with users in the home environment as well as with external users (medical doctors, nurses and family, depending on the use case). Alarm messages need to be delivered reliably. Several assistive systems either generate data that are important for the healthcare process (e.g. managed care of chronic diseases) or require

273

274

M. Eichelberg et al.

health care data such as individual thresholds for vital parameters to parameterise their decision support or alarm components. Therefore, an exchange of information with the IT infrastructure of medical professionals should be possible. Technically complex systems deployed – perhaps in large numbers – with a user group that may be technically less experienced may require capabilities of remote maintenance and a secure remote back-up so that the system status including historical measurements can be restored after hardware failure.

Finally, while the project addressed a range of very different application scenarios, it is clear that these still only make up a very small part of the number of different assistive systems that might be possible. Addressing such a large variety only becomes possible with modular, extensible systems that can be adapted to each user’s individual needs and preferences. This all supports the use of a common technical infrastructure, or platform, on which multiple different applications (assistive systems) can be installed and executed. This concept is also sometimes termed ‘‘AAL middleware’’ or ‘‘AAL software infrastructure’’. Several European research projects have worked in this field, including OASIS (4), SOPRANO (5), PERSONA (6), i2home (7), WASP (8) and, more recently, universAAL (9). While the GAL technical platform shares many commonalities with the above-mentioned projects, it is an independent development based on another European project, OSAMI (10). Privacy and security paradigm Dealing with sensitive personal data such as activity data or vital parameters requires a high degree of consideration regarding privacy and security. One important demand in this context is transparency: it must be clear to the user who is processing their data for what purpose, since a lack of transparency would cause alienation and negatively affect acceptance. Thus, the overall privacy paradigm implemented in our system is simple and transparent:

All recorded data belong to the person who generated it. The data stay on a local platform within the home environment, owned by the user. No low-level data, such as single sensor values or vital parameters, leave the platform (that is, without explicit permission of the owner). All processing of the data are done locally on the user’s platform in the user’s home. Only processed and aggregated high-level events or alarms such as a detected fall or an unhealthy behaviour are reported to the outside (healthcare professionals, relatives, etc.). The local platform is not accessible from the outside, unless the user permits remote maintenance.

From a privacy and security point of view, this sounds reasonable; from an administrative point of view, it may sound very challenging. In a distributed


and scattered deployment, it is essential to at least have some basic system monitoring capabilities, since otherwise expensive visits to the users are the only way to find out whether the system is up and running.

RESEARCH DESIGN Within the first three years of the project, the work focussed on technical feasibility, i.e. providing a common technical platform that can execute the algorithms and connect the sensors needed by the various assistive systems developed in the project. System integration and testing took place under laboratory conditions, i.e. the platform and assistive systems were integrated into the two AAL living laboratories operated by the project partners, the ‘‘IDEAAL living lab’’ in Oldenburg, and the ‘‘health-enabling technologies research laboratory’’ in Braunschweig, and tried out with healthy test persons. In the years four and five of the project, the focus shifted towards use of the platform in various studies carried out predominantly in the homes of test persons under real-life conditions:

Voice-controlled operation of the personal activity and household assistant. Sensor-based activity determination, with continuous recording of events from ambient sensors over several months with healthy, high-maintenance and mentally handicapped persons (11). Sensor-based home activity monitoring of geriatric fracture patients in rehabilitation.

While planning these studies, it quickly showed that several extensions were needed to the platform to make it suitable for a roll-out with a larger number of users (about 40 installations in different houses were planned in total). This article reports on the extensions planned and implemented, and the experiences and lessons learned from these studies with regard to the technical platform. These studies were designed and conducted in other parts of the overall project to evaluate the developed assistive technologies and not primarily to evaluate the performance of the technical platform. In this article, we report the experiences gained during these studies. No explicit field study for the technical platform has been performed.

SYSTEM ARCHITECTURE OVERVIEW In the following section, a brief overview of the architecture of the technical platform (also called Multi-Service Home Platform, MSHP) is given. More detailed descriptions can be found in (12–14). The core of the platform is written in the Java programming language, and as such is fairly platform independent. A common property of many Javabased middleware platforms (also including for example SOPRANO, PERSONA and universAAL) in this field is that they are based on the OSGi runtime environment (15). OSGi is an execution environment for Java that offers extended functions for software lifecycle management, such as the installation or update of software components at runtime, without the need to ever re-start or re-boot the overall system – at least in theory. The OSGi

275

276


Resident

Administrator

Physicians & Nurses

Monitoring & Control System (MCS)

Ambulance Service

Alert Communication

User-Interfaces

Personal Health Record (PHR)

Relatives

Configuration

1 4

Multi-User Extensions

Fall Detection

Activity Monitoring

Abstraction

Abstraction

Abstraction

OSGi Bundle: Actuator A

OSGi Bundle: Sensor B

OSGi Bundle: WBAN

OS-Driver

OS-Driver

OS-Driver

Hardware-Platform

Interface

Interface

Interface

5

Actuator A

Sensor B

2

OSGi OS

Installation Planning Tool

File System Interface

3

WBAN

Storage Interface

7

Remote Monitoring

6

Backup & Restore

VPN-Gateway Ethernet

8

2/3/4G

Distant Services: - Monitoring, Control - Backup

Figure 1. Layering and module structure of the GAL technical platform.

environment is available for the Java Micro Edition, which can be run on many embedded systems such as set-top boxes or residential gateways. Figure 1 shows an exemplary overview of the system and the layering and module structure of the technical platform. The different user groups are illustrated in the upper part of the figure. The hardware shown in the lower part provides physical interfaces for different sensors, actuators and networks. The operating system provides drivers for the different interfaces and is the basis for the application-layer driver components executing in the OSGi environment within the Java virtual machine. Connections to sensors and actuators were implemented for the following interfaces:

Home automation components, such as IR-sensors, reed contacts, switches or electrical outlets are connected either via a wired KNX network or using a wireless FS20 connection. Ultrasonic sensors for indoor localization are connected via I2C. Microphones for user interaction are connected via sound cards (both internal and USB). Cameras for image recognition are connected either through Ethernet or IEEE 1394. A wireless Body-Area Network with sensors for measuring vital parameters is connected via IEEE 802.15.4.

For every attached sensor, actuator and any other device, a representation inside the OSGi Service Platform was implemented. These representations presume working operating system drivers, which in most cases are provided by the OS or in some cases (e.g. BAN over IEEE 802.15.4) were developed within the project as well.


From the application level software components, access to sensor data takes place through an abstraction layer that hides the vendor-specific aspects and network protocol used to connect to the component and provides for a vendor-neutral interface that makes it easy to exchange one type of sensor or actuator by an equivalent component that ‘‘speaks’’ a different protocol but provides the same measurement or action. Since the general system architecture has been described in detail in (12–14), the following sections focus on the extensions to the system architecture developed specifically for the use of the technical platform in the studies carried out in the homes of test persons under real-life conditions and on the extensions intended to support and simplify routine deployment of assistive systems based on the GAL technical platform. In the following sections, the numbered items in Figure 1 will be described in detail, according to their specific number, starting with the Personal Health Record (1) for the management of the patients’ health data and the Monitoring & Control System (2) that allows the user to control the system by turning off the monitoring functions when needed or desired. While the Alert Communication (3) initiates and forwards emergency messages to relatives and health care professionals, the extensions for Multi-Person Detection (4) are able to detect whether more than one person is currently within a room or an apartment. The Installation Planning Tool (5) is a comfortable instrument to initially equip an apartment with a set of sensors and actuators. To cope with data loss, the Backup and Restore (6) system is able to securely store the data at a distant location; additionally, the Remote Monitoring (7) system provides management capabilities for multiple deployed platforms, whereas both systems take advantage of an automatically established virtual private network (VPN) connection via an integrated VPN Gateway (8). Personal health record architecture Assistive technology is often related to supporting the health of the user. Therefore, either health and care-related data are measured and acquired by the system, or health-related data such as individual boundaries for ‘‘normal’’ values of certain vital parameters are needed by the system. In each case, the question is where to keep such health information and how to exchange it with health professionals and informal carers. To address the interoperability problems of current IT systems in the healthcare domain and to establish a personal health record (PHR) system that is able to gain the full trust of the user, we use a new architectural approach that was meant to enable patients and healthy users to manage their health data by themselves. The main idea is to follow the vision of patient empowerment by giving the user the full physical control over the health data. This means that patients can download the software, install it on a PC or handheld device and start managing their own health data. Essentially, the PHR is part of the GAL technical platform and as such resides under control of the user. The software can be used either in an online or an offline mode. If the user decides to use the PHR in online mode, he/she can grant access rights to groups of people or individual persons and thereby control the data flow (top-left

277

278


Figure 2. Personal Health Record (PHR) and Monitoring Control System (MCS).

in Figure 2). In that way, family members and care givers can access the health information directly (read or read/write) through the web interface of the PHR. The main difference compared to web-based third-party PHRs like Microsoft Health Vault is that the user hosts and controls the health information on his own hardware. This gives the patient the freedom of choice to physically disconnect the hardware from the internet, so that he/she can be sure that no health information is being transferred to the outside world, as required by our privacy and security paradigm mentioned in chapter 2. This leads to the question how the patient can exchange health information when the PHR is not connected to the internet. To cover this use case, the PHR uses three interoperability profiles specified by the Integrating the Healthcare Enterprise (IHE) initiative: the XPHR (Exchange of PHR Content) interoperability profile (16) is used to generate a document with a summary of the most important medical information of the PHR owner. These documents can be transferred ‘‘offline’’ via USB memory sticks or CD-Rs in a standardized way via the Cross-enterprise Document Sharing on Media profile (17). To protect from data loss due to the loss or theft of a data medium, the content can be encrypted in a standardized way with the IHE Document Encryption profile (18). Monitoring control system The Monitoring Control System (MCS, top-right in Figure 2) is another component intended to improve the transparency and user control over the system: it displays whether or not sensor data are currently being acquired and processed and it offers the user an opportunity to temporarily deactivate the data recording and analysis.


On the one hand, there might be situations where the user wishes to stop or pause the data recording. In this case, the MCS provides a safe option to deactivate and reactivate the monitoring. This protects the system from potentially destructive user actions like pulling out the power plug or misplacing or misadjusting calibrated components. On the other hand, if other persons (e.g. relatives, friends, nurses and other service providers) are inside the user’s home, a deactivation of the monitoring may be required in order to protect the right to informational self-determination of these persons. Furthermore, the analysis of these sensor data concerning the monitored person will most likely be inaccurate due to the ambiguous assignment of the data. Main components of the MCS are a RGB status display and a remote control. The user is able to deactivate and reactivate the monitoring by means of a remote control. After the user has pressed the corresponding button on the remote control, the internal status of the MCS is updated according to the user’s request, and each monitoring component concerned is informed about the current status. Based on this status information, each monitoring component is able to react suitably, for example, in case of a deactivation by suspending the current task or by transmitting or processing of ‘‘NULL’’ values. The status display shows the current status of the monitoring. A red cross signalizes that the monitoring is deactivated, whereas a green check mark indicates an activated monitoring. However, if no symbol is shown on the display, MCS is not running. In order to configure MCS individually, the associated configuration file can be adapted to the user’s needs. This file contains, among other things, the default status, i.e. the first status after MCS has been started. In addition, this file specifies whether the monitoring previously deactivated by the user reactivates automatically after a defined period or only by pressing the corresponding button on the remote control. Alert communication The alert communication system distinguishes between two levels of alert: warnings and emergencies. Warnings depict a situation where an event was detected that potentially affects the patient’s health state in a negative way in the long term. Emergencies depict situations where immediate action is likely necessary, for example, if the patient suffers a heart attack or a breathing crisis. In order to contact the caretakers of the patient, the alert communication system extends the concept of classic emergency chains. The system attempts to establish a connection with one or more caretakers, who need to acknowledge the receipt of the message. To provide a reliable communication that fulfils the needs of different actors, it combines multiple communication channels with different communication media. The potential criticality of alarms requires a very high availability of the system. To meet this challenge, our system combines two different widely available, inexpensive, physically independent communication channels. The first prototype was developed for use in Germany and uses standard Integrated Service Digital Network (ISDN), which is mainly used in Germany, UK, Austria and Canada. The system can also use the standard GSM/UMTS mobile network (19). The hardware as well as the functionality for accessing

279

280


and switching between these networks is integrated in many current internet routers. Both communication channels permit to transmit data to systems on the internet as well as speech to other landline or mobile phones. The system currently supports transmission of speech via ISDN or GSM standard. Short Message Service data can be transferred via internet and telefax data via ISDN. The connection details of possible communication participants can be defined by the patient himself in his PHR. Multi-person detection In many cases, the algorithms processing ambient sensor data in order to extract, for example, information about activities of daily living, assume that there is only one person inside the domestic environment. This, however, is obviously not always the case, for example, due to visits by relatives, physicians or nurses. If additional persons are in the apartment, data of ambient sensors cannot be assigned unambiguously to the monitored person. Therefore, in order to protect the analysis, algorithms against inconsistent sensor data caused by multiple persons, it is useful to know if there is more than one person within the apartment or in a single room. Furthermore, a reminder service, which helps the user to recollect important dates like visiting a friend or a doctor, taking his or her medicine or doing something private, should select a suitable output medium depending on the presence of other persons, e.g. using unobtrusive information sources such as lights or vibrations instead of media such as voice output to present the reminder. Within the project, different approaches to count the number of persons inside a room were implemented and evaluated. The first three variants are similar: two ultrasonic sensors, two infrared sensors or two light barriers can be placed, one behind the other, in front of the door (on the wall or mounted to the ceiling) and used to detect the direction of a person’s motion. Figure 3 shows two ultrasonic sensors mounted to the ceiling of IDEAAL living lab in front of the bedroom door. Figure 4 shows a close-up of the sensors: carefully adjusting the angle in which the sensors are mounted helps to reduce unwanted sensor readouts caused by the environment, but optimizing each individual sensor position is obviously rather a time-consuming process. When ultrasonic or infrared sensors are used, background subtraction is required to separate between sensor events caused by a person and those caused by the static environment. Besides the influences of the static environment, the distance between two sensors or light barriers is very important due to the required sequence of sensor events caused by a person passing through the door (at first, no sensor/light barrier reports activity, then only one sensor/light barrier reports, then both, then only the second sensor/ light barrier and finally there is no activity anymore, thus completing the sequence). Therefore, a drawback of these three variants is the precise (and thus time-consuming) positioning of the sensors or light barriers that are required to make the recognition work reliably (Figure 4). Another approach is the usage of sensor mats. For this purpose, the Future Shape SensFloor can be used. SensFloor is a commercially available product that can easily be placed in front of the door to the room considered. Within the project, the supplied software analysed the data from the sensor mat and was able to


Figure 3. Two ultrasonic sensors mounted on the ceiling of the corridor in front of the bedroom (left); close-up view of the mounted sensors (right).

Figure 4. Mounting of ultrasonic sensors on the ceiling: using different angles to reduce environmental influences and to enhance the required sequence of person- and environment-caused echoes.

detect the direction of a person’s motion and to count the number of persons entering or leaving the room. Installation planning tool The Installation Planning Tool supports the installation of the system in individual apartments with regard of the number of sensors required and a suitable positioning of these sensors. For this purpose, a floor-plan of the apartment as well as information about furniture that may influence the presence or motion paths of the monitored person are needed. The installation planning tool can import such models in the common Wavefront OBJ file format, which can be generated for example with the open source interior design application Sweet Home 3D (Figure 5). Once a room model with floor plan and furniture has been imported, the planning tool creates an abstracted room model. For this purpose, the imported objects are classified by the user into walls, openings and furniture that is either relevant or irrelevant for the further planning process. The abstracted room model is two-dimensional and contains objects only the paraxial

281

282


Figure 5. Creation of a three-dimensional model of the floor-plan and furniture using the free interior design software Sweet Home 3D.

Figure 6. Installation Planning Tool showing an abstracted 2D model of the apartment and furniture.

bounding boxes of the objects that have been marked as relevant during the import process (Figure 6). An important feature of the tool is the support for sensor positioning. The user can add different sensors to the room model by adding relevant


sensor information, especially the coverage area of each sensor. A coverage area of a sensor can either be drawn in the visualization of the room model or be associated with an abstracted room model object. This enables the user to check that each relevant location is covered by at least one sensor. Based on the extended abstracted room model, the tool can furthermore determine possible motion paths between sensors by the means of a path planning algorithm. The implemented potential field method detects motion paths between adjacent sensors. Two sensors are adjacent if there is a path between the corresponding coverage areas that does not contain a coverage area of another sensor. The detected adjacency relations are drawn inside the abstracted room model. As part of this model, these relations can be used to check the sensor positions within the planning phase, to detect a second person inside the domestic environment or defective sensors in the apartment. Remote backup and restore The technical platform needs to persistently store various kinds of data: on the one hand, there is rarely changing ‘‘static’’ data such as the system configuration, floor-plan, configuration of sensors and contact information for warning and alarm messages, on the other hand, there is a continuous influx of raw sensor data that need to be kept for sufficiently long to enable long-term analysis of behavioural trends, and finally there is the derived health information stored on the PHR. Losses of these persistent data can be caused by a number of reasons. First of all, hard disks may fail mechanically or electronically. While the risk of data loss due to hard disk failure may be reduced by local fault tolerance such as a redundant array of independent disks, this would increase costs and power consumption of the system and not prevent data loss caused by software failures or an unintended deletion, e.g. by a system administrator. Therefore, a periodic backup of the system data is needed, in particular, since the loss of sensor data may negatively affect the system’s ability to determine long-term trends in activity or behaviour for several months. With a system intended for a user group that may not be able or willing to perform such maintenance, an automated remote backup is the means of choice. Certainly the transfer of a backup of sensitive information, over an Internet connection, to a remote location should take place in encrypted form. Furthermore, it is desirable that the encryption key is not available to the operator of the server to which the backup is transferred, which renders technologies such as Transport Layer Security (TLS) insufficient for this use case. It should be noted that Public Key Infrastructure is neither needed nor useful for our purpose of backup encryption: The only system or person that shall be able to decrypt the backups is the owner, respectively his/her system (MSHP). Symmetric encryption is fully sufficient as long as the encryption algorithm is secure and the key is kept secret. One shortcoming of encrypted backups is that no direct differential or incremental backup to the remote location is possible: to save space and bandwidth it is an established strategy to only backup data that has changed either since the last full backup (‘‘differential’’) or since the last incremental

283

284


Figure 7. Backup strategy for encrypted backups. A backup is first performed locally and unencrypted; the encrypted backup can then be sent to the remote storage provider. Restore and decryption works vice versa.

backup (‘‘incremental’’). As differential and incremental backup processes need to know what has been backed up before, and decryption of the remotely stored last backup is not desirable, a simple workaround comes into play, as shown in Figure 7. The current set of local, unencrypted backups (archives) since the last full backup are simply kept on the system (MSHP) as reference for future incremental backups. With the amount of data stored in the system, and the ever-increasing storage capacity that is growing according to Moore’s Law, this redundant storage approach is not a problem. The encrypted backups can then be sent to a remote storage provider and may be deleted from the local hard disk after transmission. To ensure the integrity of a remotely stored backup, a checksum for each (incremental) backup is created and stored locally. Note that the storage provider does not have to meet any specific requirements regarding security or trust, as only the locally stored key (which the user should also keep on a safe storage medium such as a memory card) is able to decrypt the data. This backup strategy may at first seem to contradict the privacy paradigm as explained in the section ‘‘Privacy and security paradigm’’. However, since only encrypted data is transmitted to a remote location, and the encryption key is never sent, the privacy of the data is guaranteed as long as the encryption algorithm is secure. Furthermore, the system needs to ensure that the backup is transmitted to the right recipient, e.g. in order to prevent a man-in-the-middle attack on the availability of the backup for restore purposes. This issue is addressed in the section ‘‘VPN gateway’’ below. Finally, it has to be kept in mind that with ongoing progress in cryptography on the one side and growing computation power on the other side, it is only a question of time when, independent of the current choice of encryption algorithm, the key length has to be extended or the algorithm has to be exchanged. Therefore, the encrypted backup should be stored at a place where it can reliably be deleted when no longer needed (i.e. after the next full backup).


Remote monitoring For a system that may on the long term be deployed in large numbers, the possibility to offer a remote monitoring of the system is essential. System monitoring is not remote maintenance – in fact, monitoring comes first and when the monitoring process detects a system failure, remote maintenance of the system can be the next step to try to fix the problem. However, any remote maintenance access clearly breaks the privacy and security paradigm as described in the section ‘‘Privacy and security paradigm’’ and, therefore, needs to be carefully considered. In (20), we stated that the seemingly first and easiest step towards remote system monitoring is a simple heartbeat message. One system just ‘‘pings’’ another system at regular intervals to determine that it is still alive and working. As the capability of sending and receiving ping (ICMP echo request) messages is implemented in nearly every operating system, this functionality can easily be implemented. At a central monitoring instance where the heartbeat messages from the distributed MSHP systems are received, an administrator could gain a rough overview of the scattered systems. A systemic shortcoming of such heartbeats is the low information content. The only information is that the system is powered up, the Internet connection is working and the process generating the heartbeat messages has not crashed. On the other hand, such a simple strategy can easily go in hand with the privacy paradigm as long as the MSHP only sends these messages and does not listen to incoming requests. However, there are security issues as well: ICMP messages are transmitted in plain text and thus not only the central monitoring instance is able to receive the heartbeats – any system on the path can read that (admittedly not very sensitive) information. The bigger additional risk is that the sending of ICMP messages requires an access (at IP level) to the Internet, which in turn requires a well configured and maintained firewall and a frequently updated system to close possible security holes in every part of the system. It is surely possible to configure a firewall to only allow outgoing ICMP messages, but that is not very flexible either. For a more complex monitoring scenario or for a future remote configuration and control of the system, a smarter solution is needed. From the privacy and security paradigm, we know that the system must not be accessible from the outside. Thus, all communication must be initiated by the system itself. This is also beneficial when looking at the different Internet connections of the deployment: A system behind a network address translation (NAT) router or a firewall can only be reached from the outside with appropriately configured forwarding mechanisms in the router/firewall; this may (with some effort) be possible for most home routers – but impossible when dealing with a second NAT at the provider side, e.g. when using a wireless 3G connection. Thus, the establishment of the connection should be performed by the MSHP systems anyway. Realizing communication integrity over insecure and uncontrollable channels like the Internet requires an authentication of the involved partners and an encryption of the data. This can either be achieved by specialized protocols like SSH/TLS or by securing all traffic by tunneling a through VPN.

285

286


VPN gateway A VPN provides a secure tunnel that connects two systems or networks through an insecure network such as the Internet. All VPN solutions have in common that data are encapsulated at the entry point to the tunnel and expanded at the exit point. This encapsulation always implies an overhead. In (21), the major implementations are compared. The Layer 2 Transport Protocol (L2TP) (22), Internet Protocol Security (IPSec) (23) and the Point-to-point Tunneling Protocol (PPTP) (24) are well-established (and fairly old) Internet standards. The developer of PPTP, Microsoft, nowadays advises against using it because of major security flaws. As L2TP is just responsible for tunneling and not for encryption, it is often used in combination with IPsec. IPsec itself is located at the network layer (Layer 3) and because of that not easy to integrate in existing networks. Especially in changing or mobile networks, L2TP and IPsec are complicated and difficult to setup. Peer-to-peer VPNs like ‘‘tinc’’ (http://www.tinc-vpn.org/) do not meet the demands of our centralized monitoring approach. After reviewing major VPN solutions, we decided to use OpenVPN (http://www.openvpn.net) for our purposes. OpenVPN is a so-called Secure Socket Layer (SSL) VPN, utilizing TLS (25) (which is as well an Internet standard). It utilizes the free OpenSSL (http://www.openssl.org/) implementation. Both are open source software. In Figure 8, the basic functionality of OpenVPN is shown. OpenVPN provides a virtual network adapter (that to the software layer ‘‘looks’’ like an additional Ethernet interface) to the operating system. All network traffic using this interface is encapsulated (encrypted) and forwarded through a secure tunnel. The tunnel is established between an OpenVPN client (MSHP) and a server, the VPN concentrator. The concentrator again also has virtual network interfaces – one for every connected client. While configuring such a VPN, it can be decided whether the traffic of the connected clients is bridged (the clients can exchange data among each other on data link level) or routed (the routing instance of the concentrator decides). As a communication between MSHPs is not intended, the routed interface is used, with no routes between the individual MSHPs. For each MSHP installation, there are just two rules to be configured to keep the system safe:

From the ‘‘outside’’ (i.e. the Internet), nothing is accessible. The only application that is allowed to use the regular network interface is the OpenVPN process – for outgoing connections only. Concentrator

Intermediate Systems (IP Router)

MSHP Virtual Interface

5: Application

OpenVPN

OpenVPN

Application

4: Transport

TCP/UDP

TCP/UDP

TCP

3: Network

IP

IP

IP

Ethernet

Ethernet

2: Data Link 1: Physical

Ethernet

IP 2: Data Link 1: Physical

Figure 8. OpenVPN functionality: the application layer protocol provides a virtual interface that acts like a common Ethernet interface and enables end-to-end encrypted communication through every intermediate system to a VPN concentrator (20).


All other processes (e.g. heartbeat sending and remote backup) are bound to the virtual VPN interface and thus only able to communicate with the concentrator.

The MSHP can be preconfigured before installation; after being powered on and connected to any kind of Internet access it establishes a secure tunnel to the concentrator which then can start monitoring the system. A common and widely used protocol for system monitoring is the Simple Network Management Protocol (SNMP) (26) that currently exists in three versions and is implemented in most professional network devices. The SNMP versions most widely supported are versions 1 and 2, which provide no security mechanisms at all, but can securely be used over the VPN tunnel. It should be noted that SNMP may also allow write access to the supported devices, depending on the configuration, which can be seen as the first step towards remote configuration, but also as a break of the privacy paradigm. In Figure 9, the basics of the remote monitoring (and control) system are summarized. The distributed MSHP systems set up a VPN tunnel to a concentrator, whereas the communication channel can be assumed as safe and secure. Only the VPN client is able to access the external interface and every communication that leaves the MSHP system is encapsulated. The VPN concentrator acts as counterpart for the VPN tunnels. In this study, the unencrypted monitoring data is available to the monitoring application, which must, therefore, be protected from unauthorized access and use.

MAIN OUTCOME AND RESULTS The formerly described technical setup was used in four different field studies. The majority of these studies were conducted in the context of the GAL project, but the technical platform was also used in other AAL-related projects such as: Mneme (‘‘Design of a telemedical health services model for dementia patients in their domestic environments’’) (27) and ‘‘Platform for the integration of technology-based health services on health networks’’ (PAGE) (28). The field studies focused on individual research questions in partly different environments. The studies were performed in order to evaluate the specific assistive Monitoring Instance

VPNConcentrator

MSHPs

1 Internet n

Figure 9. Monitoring over a virtual private network. Each MSPH establishes a VPN connection to a concentrator. All communication is secured by authenticated and encrypted VPN tunnels. The data are then processed and presented by a monitoring instance (20).

287

288


technologies developed in the respective project or sub-project – the technical platform and the presented functionalities and enhancements were tested within these studies. Thus, in addition to the ‘‘normal’’ evaluation of the specific assistive technology, many tasks were performed to gather data regarding the functionality and the underlying technical infrastructure: The technicians took pictures and annotated them, performed interviews with inhabitants and caretakers before, during and after the installation. The GAL-NATARS study lasted 12 months and focused on patients with mobility impairing fractures in overall 14 private flats (29). The technical platform is still in use in the GAL study on sensor-based activity recognition, which is running for 20 months by now. Different variants of the technical setup have been installed in a residential institution for people with mental disabilities and also in different private flats. The patients in this study live with different restrictions: two patients are mentally handicapped, two patients with need of care, one of them has multiple sclerosis and three patients without need of care, but with age-related diseases (30). The technical setup was also used in the Mneme project, which focused on patients with dementia. This study lasted three months and was conducted with six patients. The PAGE project focused on patients with age-related restrictions, and the study was conducted over one month with an overall number of five participants. Over a period of more than two years, the technical platform has been in use in more than 30 different residential environments and with users with heterogeneous health restrictions. The platform has been developed constantly over time and has been adapted to the individual settings. The following results represent the summarized technical challenges and experiences of these field studies. Challenges caused by the technical setup Overall, there were few technical problems with the installed system and sensor setups. One unexpected factor was the missing Internet access: none of the older adults who volunteered as test persons for the field studies had any Internet access at home, so no remote system monitoring or backup was possible. Since the system worked stable and the sensor data was stored on an SD card that was collected by the study monitors once in a week, this was not critical for the field studies. However, the lack of Internet access rendered the online interface of the PHR and the Internet-based alert communication useless for the field trials. The PHR system has the ability to compensate the missing Internet connection by an offline data exchange over storage media like USB-sticks. However, this functionality was not used in the field studies, because there were no clinical IT systems involved that could have read, imported and processed the aggregated health data from the storage media. Despite the national efforts in Germany to set-up a national health telematics infrastructure that could provide for an Electronic Health Record, neither the health telematics infrastructure nor the current IT systems in hospitals are ready to import health data maintained by the patients themselves, or generated by AAL systems. Another tool that was not used in the field studies was the installation planning tool for the sensor placement. For most of the apartments, no floor


plans were available, so time-consuming manual measurements would have to be performed by the technicians prior to each installation. Furthermore, patients complained about the positioning of sensors by the technicians, because they perceived the sensors as being too ‘‘visible’’, so the sensor positioning often had to be changed spontaneously during installation. In the field study with mentally handicapped persons, the radio transmissions of the wireless FS20 sensors were initially unreliable. This problem was addressed by installing a PC inside the participant’s room (in a ‘‘hidden’’ place) that captured the sensor data and transmitted it over a Wireless LAN repeater to the PC of the night watch. Furthermore, the door contact switches were disturbed by metal door frames. After a few experiments, we solved this problem by placing small plastic spacers between the sensor and the metal. Unplanned events and use of technology Initially the use of nine decentralised Plugwise power sensors per household was planned for the field studies. In practice, it showed none of the participants had enough electrical devices that operated permanently on the same socket to warrant installation of all of the sensors. The MCS was used in an apartment of a person with multiple sclerosis to preserve the privacy of the caregivers: the monitoring system was deactivated by the caregiver while care was provided at daytime and reactivated when the caregiver left the apartment in order to gain more information about the nightly activities of the inhabitant. When discussing the visualisation of the sensor data with care personnel (nurses and doctors), we learned that when retroactively analysing data, the users preferred a view with a timeline on the horizontal axis and the detected events on the vertical axis. However, when the sensors were used to assist the night shift and showed the events in real time, they rather preferred a view that shows the floor plan and the location where an event has been detected. Challenges caused by the participants and human factors As expected, the participants turned out to be the most unpredictable influence factor on the data acquisition process and consumed (by far) most of the time of the technicians involved in the field studies. One participant moved a piece of furniture in the way of a light barrier, thus preventing this sensor from correctly detecting people walking through one door. In other cases, the participant placed a bag and clothes in front of a sensor, with a similar result. One participant refused to wear the mobile accelerometer used in that specific study and also intervened when ambient sensors were placed inside the flat, in both cases due to aesthetical reasons. Finally, permission to install the ambient sensors was granted under the condition that they be removed if they turn out to be disturbing – which never happened: after two weeks, the participant stated that she did not notice the system anymore, and the sensors remained in their original placement. The communication with one participant was disturbed for two months as neither landline nor mobile phone worked anymore – the study personnel arranged appointments by postcard. Attempts to arrange an appointment with a multimorbid participant failed over more

289

290


than one year because of the participants’ illness, interrupting appointments and difficulties to reach the participant by phone. Overall, it seemed helpful to arrange the appointments on a weekly basis on the same fixed day of the week. This regular personal contact seemed to be a huge motivation for nearly all the participants. The acquisition of the participants was more successful if it was initiated by personal contact (e.g. a friend or the home management). Another critical success factor before the beginning of the study was the personal meeting with the study monitor that looked after the participant. Consequently, most of them showed their regret to lose this contact at the end of the study.

DISCUSSION AND CONCLUSION Field studies are elaborate and costly; performing a field study only to evaluate the functionality of the technical platform and its enhancements was neither affordable nor sensible in the overall structure of the GAL project. However, the fields studies performed to evaluate the assistive systems developed in the project gave us an opportunity to test and evaluate the technical platform under realistic conditions. The field studies showed that the fundamental concept of the technical platform is valid, and the prototypes continuously worked 24 h a day for several months; systems were checked during the weekly visits of the study monitors; and there was rarely a need to restart a system. The approach to planning and installation of the systems during the field studies was rather ad-hoc, with both planning and installation typically taking place during the first visit to the study participant’s home, over a period of 2–4 h. Our experience showed that there is a significant part of the planning that can only be addressed during the system installation in the apartment since typically no proper floor plans are available, the placing of furniture is not known in advance, and there are important details such as metal door frames, which require special handling but would certainly not be marked as such on a floor plan, even if one was available. Furthermore, individual preferences of the participants (e.g. the desire to not have ‘‘ugly’’ sensors be installed in overly visible places) are also difficult to address in advance. While this was not a problem for a study setting, it is an open question how a roll-out of such assistive systems for thousands of customers could be efficiently planned and performed. One problem in our field studies was the total absence of Internet connections in all study participants’ homes. This required regular visits by the technical staff and prevented the use of some system components in the context of our field studies – these components, such as the alert system, the remote monitoring and backup component, and the PHR system were only tested in our laboratory environments. For a large-scale roll-out, however, services such as remote monitoring and an automated backup of the system would be indispensable. Therefore, such systems would routinely have to be equipped with their own Internet access (e.g. UMTS-based), which needs to be taken into account in the design of the business model. Another factor to be taken into account in a large-scale roll out is the maintenance concept. The absence of any home automation infrastructure in the homes of our study participants showed that the decision to use sensors


with wireless network protocol was right, and in most homes the radio transmission worked without problems. However, electrical outlets were not always available at the position of the sensors, and while battery powered sensors were not a problem in a study setting where the participants were visited regularly, changing batteries in several sensors could very well be an issue in a large-scale implementation. Remote system monitoring can help by regularly transmitting the battery status of each sensor to the monitoring centre, thus helping to plan maintenance visits appropriately before sensors fail due to drained batteries. Nevertheless, the requirement to plan such visits on a regular basis is a cost factor that needs to be accounted for. Finally, our study has again confirmed that technology is only accepted in the living environment if it is either ‘‘invisible’’, or looks attractive – aesthetical aspects thus clearly play a role in the design of components for assistive systems. In summary, the authors believe that making complex technologies work for users with little technical experience is well possible, but requires a careful consideration of the complete service chain and the related ‘‘soft factors’’ such as aesthetical aspects.

DECLARATION OF INTEREST The authors report no conflicts of interest. The authors alone are responsible for the content and writing of this article. The Lower Saxony research network ‘‘Design of Environments for Ageing’’ acknowledges the support of the Lower Saxony Ministry of Science and Culture through the ‘‘Niedersa¨chsisches Vorab’’ grant programme (grant ZN 2701).

REFERENCES 1. UN Department of Economic and Social Affairs, Population Division [Internet]. Population aging 2002. Available from: http://www.un.org/esa/population/publications/ageing/Graph.pdf [last accessed 21 Aug 2013]. 2. European Commission, Directorate-General for Employment, Social Affairs and Equal Opportunities Unit E.1. The demographic future of Europe – from challenge to opportunity. October 2006. Available from: http://ec.europa.eu/social/ BlobServlet?docId¼2023&langId¼en [last accessed 21 Aug 2013]. 3. Haux R, Hein A, Eichelberg M, et al. The Lower Saxony research network design of environments for ageing: towards interdisciplinary research on information and communication technologies in ageing societies. Inform Health Soc Care 2010;35: 92–103. 4. Kehagias DD, Kontotasiou D, Tzovaras D, et al. Preliminary Architecture of the OASIS Content Connector Module. Ask-IT Final Conference; 2008 June 26–27; Nuremberg, Germany. 5. Wolf P, Schmidt A, Klein M. SOPRANO – an extensible, open AAL platform for elderly people based on semantical contracts. 3rd Workshop on Artificial Intelligence Techniques for Ambient Intelligence (AITAmI’08), 18th European Conference on Artificial Intelligence (ECAI 08); 2008; Patras, Greece. 6. Tazari MR, Furfari F, Lazaro Ramos JP, Ferro E. The PERSONA Service Platform for AAL Spaces. Handbook of Ambient Intelligence and Smart Environments (AISE). New York/Dordrecht/Heidelberg/London: Springer; 2009.

291

292


7. Nesselrath R, Schulz C, Schehl JM, et al. Homogeneous multimodal access to the digital home for people with cognitive disabilities. Proceedings 2. Deutscher AAL-Kongress, Berlin, Germany; 2009. 8. Bennebroek M, Atallah L, Lo B, Yang GZ. Remote elderly care monitoring in WASP. European Conference on Wireless Sensor Networks (EWSN), Coimbra, Portugal; 2010. 9. Hanke S, Mayer C, Hoeftberger O, et al. UniversAAL – an open and consolidated AAL platform. Advanced technologies and societal change. Ambient Assisted Living; 2011:127–40. 10. Lipprandt M, Eichelberg M, Thronicke W, et al. OSAMI-D: an open service platform for healthcare monitoring applications. Proceedings 2nd International Conference on Human System Interaction, Catania, Italy; 2009:139–45. 11. Steen EE, Frenken T, Eichelberg M, et al. Modeling individual healthy behavior using home automation sensor data: results from a field trial. J Ambient Intell Smart Environ 2013;5:503–23. 12. Bu¨sching F, Doering M, Wolf L. Integration of an ‘‘Environments for Aging’’ Platform in SOHO-Routers. Proc 14th IEEE International Symposium on Consumer Electronics (ISCE2010); 2010 June; Braunschweig, Germany. 13. Eichelberg M, Hein A, Bu¨sching F, Wolf L. The GAL middleware platform for AAL – a case study. Proceedings First International Workshop on AAL Service Platforms (WASP 2010), 2010 July 2; Lyon, France, pp. 1–6. 14. Hein A, Eichelberg M, Nee O, et al. A service oriented platform for health services and ambient assisted living. Proceedings SOCNE 2009 – 4th International IEEE Workshop on Service Oriented Architectures in Converging Networked Environments; 2009 May 26–29; Bradford, UK, pp. 531–7. 15. The OSGi Alliance. OSGi service platform core specification release 4, Version 4.2; June 2009. 16. Integrating the Healthcare Enterprise. Patient care coordination (PCC) technical framework. Volume I Revision 8.0; 2012. 17. Integrating the Healthcare Enterprise. IT Infrastructure Technical Framework Volume 2b (ITI TF-2b) Transactions Part B, August 2012. 18. Integrating the Healthcare Enterprise. Document Encryption (DEN) – draft for trial implementation; 2011. 19. Redl S. An Introduction to GSM. Boston: Artech House; 1995. 20. Bu¨sching F, Bottazzi M, Wolf LC. The GAL monitoring concept for distributed AAL platforms. 2012 IEEE 14th International Conference on e-Health Networking, Applications and Services (Healthcom), Beijing, China. 21. Khanvilkar S, Khokhar AA. Experimental evaluations of open-source linux-based VPN solutions. Proceedings of the International Conference On Computer Communications and Networks (ICCCN 2004), October 11–13, 2004, Chicago, IL, USA. IEEE; 2004:181–6. 22. Townsley W, Valencia A, Rubens A, et al. Layer two tunneling protocol ‘‘L2TP’’. Request for Comments 2661; August 1999. 23. Patel B, Aboba B, Dixon W, et al. Securing L2TP using IPsec. Request for Comments 3193, November 2001. 24. Hamzeh K, Pall G, Verthein W, et al. Point-to-point tunneling protocol (PPTP). Request for Comments 2637; July 1999. 25. Dierks T, Rescorla E. The transport layer security (TLS) protocol, Version 1.2. Request for Comments 5246; August 2008. 26. Levi D, Meyer P, Stewart B. Simple network management protocol (SNMP) applications. Request for Comments 3413; December 2002. 27. Wallbaum T, Frenken M, Meyer J, et al. Mneme – telemonitoring for medical treatment-support in dementia. Proceedings 6. Deutscher AAL-Kongress, Berlin, Germany; 2013:138–45. 28. Steen EE, Frenken T, Frenken M, Hein A. Functional assessment in elderlies’ homes: early results from a field trial. Proceedings 6. Deutscher AAL-Kongress, Berlin, Germany; 2013:3–17.


29. Marschollek M, Becker M, Bauer J, et al. Multimodal activity monitoring for home rehabilitation of geriatric fracture patients – feasibility and acceptance of sensor systems in the GAL-NATARS – Study. Inform Health Soc Care 2014;39(3–4): 262–271. 30. Hein A, Steen EE, Thiel A, et al. Working with a domestic assessment system to estimate the need of support and care of elderly and disabled persons: results from field studies. Inform Health Soc Care 2014;39(3–4):210–231.

293

Copyright of Informatics for Health & Social Care is the property of Taylor & Francis Ltd and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use.

Perfluoroalkane force field for lipid membrane environments.

Rocking platform for paraplegic patients in wheel chairs. Technical note.

Phenoliner: A New Field Phenotyping Platform for Grapevine Research.

Lessons Learned from Three Models that Use Small Grants for Building Academic-Community Partnerships for Research.

Microarchitecture for a three-dimensional wrinkled surface platform.

Retaining traditionally hard to reach participants: Lessons learned from three childhood obesity studies.

GESDB: a platform of simulation resources for genetic epidemiology studies.

Conditional Random Field-Based Offline Map Matching for Indoor Environments.

[Lessons from Field Studies].

[Urotechnology: a new interdisciplinary platform for promoting and managing of technical innovations in urology].

Leveraging the EHR4CR platform to support patient inclusion in academic studies: challenges and lessons learned.

A nondivergent three field matching technique for breast irradiation.

Lessons learned from genetic testing for channelopathies.

Three Lessons Learned.

Using the Clinical Research Network for psychosocial cancer research: lessons learned from two observational studies.

Novel targets for the prevention of osteoporosis - lessons learned from studies of metabolic bone disorders.

Predictors for clinical outcome in psoriatic arthritis - what have we learned from cohort studies?

Predictions for water clusters from a first-principles two- and three-body force field.

Reporting individual results for biomonitoring and environmental exposures: lessons learned from environmental communication case studies.

Piloting a nationally disseminated, interactive human subjects protection program for community partners: unexpected lessons learned from the field.

Designing with protocells: applications of a novel technical platform.

KinomeXplorer: an integrated platform for kinome biology studies.

Three-field vs two-field lymph node dissection for esophageal cancer: a meta-analysis.

Novel tunneling system for implantation of percutaneous nerve field stimulator electrodes: a technical note.