# A Scalable Solution to Detect Behavior Changes of Elderly People Living Alone
## Appendix A
### Requirements for the Software Components of the System  
The software application used for monitoring should be easy to use and require only a limited knowledge of how to operate digital equipment in general. We suggest a hybrid approach, with the option to use either a mobile application (most elderly people possess smartphones), or a web application that can be accessed from anywhere, using a computer that might already be present in the household, or a more specialized piece of hardware with a touchscreen for even simpler interaction.  
The graphical user interface (GUI) would be part of a framework that would handle the integration of the presented algorithm with the sensors and coordinate communication between the connected households.  
This framework can be designed as a traditional client-server application, where the business logic resides on the server (backend) and the data is visualized in the frontend.  
The backend would be built on top of an event-driven architecture since real-time situational awareness is required. It consists of an event router (also known as an event bus) and several event producers and consumers (see Figure 10). In this application, each participating household would be an event producer and consumer at the same time.  
We would specifically use the Publish/Subscribe model because it allows automatic transmission of events to all (or a subset of) subscribers. Subscribing to the event stream would require little to no interaction, as each participant can be pre-configured to join the default event stream.  
Since the data is exchanged over the network in binary format, the messages could contain any type of information relevant for the consumers, including images, or plain text.  
For security reasons, the information about the identity of the peers should be stored on the remote server and made available only to authorized caregivers for emergency situations.  
The system should be able to define and configure smaller groups, each containing 4-5 households for easier monitoring. Ideally, all the configuration and maintenance operations could be executed remotely. For example, a group could allow automatic subscription based on a group identifier that could be designed to encode valuable information, such as the identity and the address of the users, or some other arbitrary information that the administrator of the framework uses to group households. Proximity to each other could represent an important criterion, but other metrics could also be used, such as the age or some medical condition of the participants.  
The system should be able to serve a large number of monitoring groups of participants. The only limitation would be the processing power of the event router, i.e., the servers that run the backend application. Ideally, such a system would run in a cloud provider that can easily handle quick scaling.  
The frontend application should be designed to display the relevant information for the other peers enrolled in the system, with a focus on the simplicity of the presentation. The main screen of the GUI would contain the profile pictures of the members of the monitoring group, along with an image showing their current monitoring status. This can be a simple emoticon on a color-coded background (e.g., a smiling face on a green background if the monitoring status is normal, a neutral face on a yellow background for alerts rejected by the alert filtering module, and a sad face on a red background to indicate alerts) or can be an image like the one shown in Figure 7d.  
It also should include the option to request assistance for either themselves or for a peer whose monitoring unit generated an alert.