Overview of the Sherpam system
Project Sherpam aims at monitoring continuously the health status of people during their daily activities. A system for data acquisition, transmission, and processing is therefore required that meets the following criteria:
Since distinct pathologies may require different types of data the system should not be limited to a pre-defined, immutable set of sensors, but it should on the contrary be extensible so as to easily accommodate new types of sensors whenever needed;
The system should allow that data acquired by sensors be processed either "locally" or on a remote site. Local processing makes it possible for the sensing system worn by a subject to run autonomously --though possibly in a degraded mode-- when no communication network is available. In contrast remote processing makes it possible to run advanced (CPU intensive) algorithms on the data collected by the sensors.
The system should be agile regarding network connectivity, switching from cellular (2.5G/3G/4G) networks to Wi-Fi hotspots depending on their availability, but also depending on other parameters such as the nature of the data to be transmitted or the power consumption involved when using each kind of network.
The system should be able to tolerate disruptions in network connectivity, including long disruptions as can be observed in "white zones" that are not covered by any wireless network.
No system meeting all the criteria listed in the above paragraph is openly available to date. Part of the work conducted in project Sherpam has therefore been devoted to designing and implementing a prototype system that meets these criteria. To date the source code of this system is composed of about 170 Java classes, which together contain about 17.000 lines of code.
An overview of this prototype system is provided in Figure 1. This system encompasses all stages of data acquisition, transmission, and processing, and each of these operations can be performed automatically and continuously.
Before transferring data to a remote site, the gateway can pre-process these data in order to reduce the amount of data to be transferred, or in order to detect interesting patterns in these data. In the latter case, the subject can be warned directly by audible or visual notifications.
Since the Android OS does not allow an application to load external classes at runtime, an original plugin system has been developped for this project's Android app. With this plugin system, software modules can be "plugged in" the application at any time, each module being designed to drive a specific type of sensor. With this feature, the Android app is highly modular, as new types of sensors can be included at any time in the Sherpam system, without requiring any update of the app itself.
The front-end of the “remote site” is an aggregation server, whose role is to receive the bundles sent by mobile gateways, to extract the data contained in these bundles, and to store these data so they can be accessed by processing units.
A processing unit is typically an application that subscribes with the server in order to receive all data pertaining to a given patient, and to process these data continuously and autonomously, looking for interesting patterns (for examples signs of arrythmia in a stream of ECG samples). When a processing unit detects anything interesting or unusual, a notification can be sent automatically to medical staff, or directly to the patient.
A very basic processing unit has been developped to serve as a demonstrator in project Sherpam. This unit is simply a Web server (Fig. 3), which makes it possible to parse the data stored on the aggregation server, to visualize data sets, and to download selected data for further analysis.
- The real identity of the patient is never associated with the data collected and processed by the Sherpam system. Instead a neutral identifier is used, and this identifier is included in the meta-information of each data bundle. Matching a dataset with the corresponding patient's real identity is only possible for medical staff;
- The data bundles stored in a wearable gateway are encrypted (using AES-256 encryption), so the data they contain are safe in case the gateway is lost or stolen;
- All transmissions between the gateway and the aggregation server are encrypted using the TLS suite, which prevents eavesdropping and data tampering;
- Once a TLS session is established between the gateway and the aggregation server, the gateway must authenticate before being able to send any bundle, so the server's database cannot be corrupted by faked data;
- Once they reach the aggregation server the bundles are processed locally, and the data they contain are stored in the local filesystem in an encrypted form (so the data they contain would be safe even if the server was compromised);
- The server can —and should!— be installed in a data-center providing standard security measures, such as restricted access, reliable backup procedures, redundant power source, fire prevention, etc.
Prospects for future work
The prototype system developed in the framework of project Sherpam is extensible. Future extensions might cover:
- The implementation of data processing algorithms to be embedded directly on the gateway, so it can run autonomously when network connectivity is disrupted.
- The implementation of advanced (and possibly resource-greedy) data processing algorithms to be run on dedicated processing units.