Table 2.

Use cases considered for the definition of the system.

Use Case	Description
User authentication	Once the user is registered in the application, the credentials are verified and the user is redirected to the main page of the application. Pre-condition: a user must be registered by the system administrator
Data acquisition	Once the patient has logged in, they can access the monitoring functions of the application. The health professional may also access the monitoring functions of his assigned patients. To do this, an historical data tab should provide navigation functions to select a patient and a sensor. The patient can also enter data manually into the application. Pre-condition: successful log in
Sensors management	The health professional is in charge of the management of sensors in the application, therefore, once logged in, sensors assigned to patients can be registered, modified or removed. To modify or remove a sensor, the user will have to select it from the sensor list. Pre-condition: authentication as health professional
User management	The system administrator is responsible for registering, unregistering and modifying the users of the application. If a user is a patient type, they must have an assigned doctor; if the user is a doctor, it can contain a list of assigned patients. To modify a user, the administrator will have to select it from the list of users.
Interoperability	Each data point acquired by the sensor and monitored by the application is stored in the local database. Once the data have been validated by the FHIR standard, a request to the universAAL REST API is made using a POST method, which will vary depending on the type of sensor. On the server, the system must have a Publisher that will send all the data to all Subscribers who are subscribed to the universAAL service. Any external agent that meets the requirements as a Subscriber may use the service and deploy it to another system.