*5.3. Time Response of Event Warnings: Local, Fog and Cloud*

As it was previously indicated in Section 4.2, when a dangerous situation for the patient is detected, event notifications are issued. Depending on the target user, it can be distinguished among local, fog and cloud warnings. In order to measure the delay of these warnings, it can be averaged a number of significant requests (i.e., 500 requests for the fog node, 100 for the cloud and 20 for Android) in the three aforementioned scenarios.

In the first column of Figure 15 it is represented the average time required by the tested Android smartphone app to read the information from the local database and show a warning to the patient. As it can be observed, such a time is really small: only 11.9 ms.

**Figure 15.** Average notification times in different scenarios.

The second column of Figure 15 represents the average notification time of a fog node when sending a warning. Such a time is exactly 249.5 ms, and includes the time required to send a request, to process it (thus interacting with OrbitDB) and to receive the notification from the fog gateway. The third column of Figure 15 shows the longest average notification time, which is obtained when performing the same tasks previously indicated for the fog gateway, but for an OrbitDB node that ran on the cloud. In this case, the average response time was 465.8 ms.

These results for the three selected scenarios may be used when developing applications that have to comply with strict latency requirements related to critical reaction times that might be needed to warn or to send certain information to DM patients or to health devices carried by them.

### *5.4. Blockchain Performance: Smart Contracts Execution Time*

In order to detect potential bottlenecks in the proposed architecture, an additional experiment was performed to measure the response latency of the blockchain. This is specially interesting in the case of using Ropsten testnet, where the time to mint a block may vary noticeably as it uses PoW as consensus protocol.

Figure 16 shows the response latency of 1000 transactions in the Ropsten testnet during the execution of the smart contract related to the management of GlucoCoin (its main code is shown in Listing 1).

**Figure 16.** Ropsten testnet time response when executing smart contracts.

In Figure 16 it can be observed that the smart contract execution time oscillates continuously mainly due to the number of available miners (i.e., participants that execute the smart contract) and

their computational load. Specifically, the obtained blockchain response times vary significantly from less than 20 s up to more than 240 s. Nonetheless, the average blockchain time response is 36.47 s, which is not very different from the usual average time provided by Ropsten (roughly 30 s), although the standard deviation of the performed measurements was 33.96 s. These response times can be considered normal in a blockchain based on a PoW consensus mechanism, since it includes the time for sending the transaction request, the time required by the consensus protocol to select the miner that will execute the smart contract and the time needed for executing the smart contract. As a reference, it can be indicated that, in a PoW-based cryptocurrency like Bitcoin [86], the transaction execution time in June 2019 was 9.47 min [87]. In any case, it is worth pointing out that execution delay obtained in Ropsten is noticeably larger than the time response required by OrbitDB nodes, so it will have to be taken into consideration in cases where response latency is essential.

It is worth pointing out that, thanks to the use of a blockchain, any reader can check the obtained results by browsing the wallet used for the experiments on the Ropsten testnet [88]. In addition, Figure 17 shows a screenshot of the Ethereum wallet that includes the details of some of the transactions performed on the testnet.

Listing 1: Main code of the smart contract that controls GlucoCoin.

```
pragma s oli di t y >=0.4.25 < 0 . 6 . 0 ;
contract GlucoCoin {
    mapping ( address => ui n t ) balances ;
     event Transfer ( address indexed _from , address indexed _to , uint256 _value );
     constructor () public {
              balances [ tx . origin ] = 10000;
     }
     func tion sendCoin ( address receive r , uin t amount ) public returns ( bool su fficient ) {
               i f ( b al an ce s [msg . sender ] < amount ) return false ;
              b al an ce s [msg . sender ] −= amount ;
              b al an ce s [ r e c ei v e r ] += amount ;
              emi t T r a n s fe r (msg . sender , rece iver , amount ) ;
              return true ;
     }
     function getBalanceInEth ( address addr ) public view returns ( uint ) {
              return ConvertLib . convert ( getBalance ( addr ) , 2 ) ;
     }
     function getBalance ( address addr ) public view returns ( uint ) {
              return balances [ addr ] ;
     }
}
```


**Figure 17.** Ropsten testnet main view of the transactions related to the deployed smart contract.

### **6. Future Work**

Although the tests performed on the proposed system showed its practical feasibility, there are several aspects that can be further improved:


### **7. Conclusions**

This article presented the design, implementation and evaluation of an IoT CGM-based system for mobile crowdsourcing diabetes research and care. Such a system is able to collect blood glucose levels from CGMs that can be accessed remotely. Thus, the system allows for monitoring patients and warn them in real-time in case a dangerous situation is detected. In order to create the proposed system, a fog computing system based on distributed mobile smartphones was devised to collect data from the CGMs and send them to a remote cloud and/or to a blockchain. Thanks to the blockchain and the proposed CGM-based system it is possible to provide a transparent and trustworthy blood glucose data

source from a population in a rapid, flexible, scalable and low-cost way. Such mobile crowdsourced data can enable novel mHealth applications for diagnosis, patient monitoring or even public health actions that may help to advance in the control of the disease and raise global awareness on the increasing prevalence of diabetes. Furthermore, the performance of the proposed blockchain-based architecture, the decentralized database and the smart contracts were evaluated in diverse scenarios that take into account the latency demands that may be required by different potential stakeholders (e.g., patients, doctors, caretakers, scientists, government, insurance companies, governments, app developers) of the healthcare ecosystem.

**Author Contributions:** T.M.F.-C. and P.F.-L. conceived and designed the system; I.F.-M., T.M.F.-C., O.B.-N. and P.F.-L. performed the experiments; T.M.F.-C. and P.F.-L. tested the Freestyle Libre CGM sensor; P.F.-L. and T.M.F.-C. wrote the paper. Project administration, T.M.F.-C., and P.F.-L.; funding acquisition, T.M.F.-C., and P.F.-L.

**Funding:** This work has been funded by the Xunta de Galicia (ED431C 2016-045, ED431G/01), the Agencia Estatal de Investigación of Spain (TEC2016-75067-C4-1-R) and ERDF funds of the EU (AEI/FEDER, UE).

**Conflicts of Interest:** The authors declare no conflict of interest.
