*4.2. Regular Functioning of the System*

Three common use cases may arise during the regular operation of the system. The first one is illustrated in Figure 6 and represents the insertion process that is performed with the collected data. It must be noted that, before starting to use the system, it needs to be initialized: the decentralized storage nodes require to be synchronized through IPFS (steps 0A and 0B in Figure 6), the used smart contracts need to be compiled and deployed in a Ethereum testnet (step 0C), the GlucoCoin wallets have to be initialized (step 0D) and the CGM sensor has to be placed on the patient's arm. Moreover, the developed mobile app has to be installed on the patient's smartphone and the required Android permissions need to be granted so that the app can make use of the WiFi interface to detect and connect to the available fog gateways.

**Figure 6.** Insertion process for the data collected from the CGM.

Once the system is deployed and configured, the patient can read the sensor by approaching the smartphone (step 1) (note that there are amateur [63,64] and commercial [84] devices that make use of arm bands to automate this reading process). If there is a fog gateway in range, the collected glucose values are sent to it, which stores them in OrbitDB (step 2A). If there are no fog gateways in range, the smartphone sends the data to an OrbitDB node on the Internet (step 2B), which appends them to its database (step 3). Since the stored data are decentralized and therefore stored on synchronized OrbitDB nodes, an external authorized provider can access such data (step 4) and reward the patient with a number of GlucoCoins that is proportionate to his/her data contribution (step 5).

A second relevant use case is illustrated in Figure 7 and is related to the notifications performed by the system when a dangerous situation is detected (e.g., when detecting an incoming hypoglycemia). In such a case, after initializing the system (steps 0A and 0B), glucose concentration values can be read (step 1) and three notification layers may warn the user:


**Figure 7.** Patient and user notification processes.

The third relevant use case is depicted in Figure 8 and illustrates an example of smart contract execution. Specifically, this third use case refers to how a new sensor can be purchased automatically by relying on the data provided by the CGM sensor. Such a process begins after the initialization of the system (steps 0A, 0B, 0C and 0D) and requires reading the expiration date (actually, the activity time) of the sensor (step 1) and storing it either on the local fog gateway (step 2A) or on a remote OrbitDB node (steps 2B and 3). The stored data are monitored by an oracle (step 4) that feeds a smart contract (step 5) that decides whether it is time to perform the purchase of a new sensor. When such a time comes, the smart contract is executed: it is checked the patient's GlucoCoin wallet (step 6) and, if there are enough GlucoCoins, the purchase is performed (step 7). Once the sensor provider confirms the purchase (step 8), the price of the new sensor in GlucoCoins can be withdrawn from the user wallet (step 9) and the provider can send (for instance, by courier) the CGM sensor to the patient (step 10).

**Figure 8.** Process to automatically purchase CGMs due to the imminent expiration of the current one.
