## 3 System Architecture of the Decentralized Framework
### Blockchain Module  
Blockchain has emerged as an innovative technology in secure and decentralized data management, offering properties that are particularly relevant to sensitive domains such as the healthcare sector. At its core, blockchain is a distributed ledger system that records transactions in a series of cryptographically linked blocks. These blocks are designed to be immutable, ensuring that data, once added, cannot be modified or deleted, thus providing a high level of security and trust. Ethereum and other Ethereum Virtual Machine (EVM)-compatible blockchains have further advanced this technology by enabling programmable smart contracts. These contracts operate as self-executing code triggered by predefined conditions, eliminating the need for intermediaries while ensuring transparency. In ambulance dispatch and patient data management, blockchain provides a secure and reliable framework to validate the critical events, while safeguarding sensitive information. The proposed system uses an Ethereum Virtual Machine (EVM)-compatible blockchain to certify the records, kept in a cloud storage, of incident data. For enhanced security, incident data are hashed using the SHA-256 algorithm, generating a unique digital fingerprint that guarantees its integrity. This hash is then immutably recorded on the blockchain, establishing a transparent and unalterable record of all system transactions. This mechanism secures data and facilitates independent verification, as the blockchain serves as a reliable audit trail that can be referenced to confirm that the recorded data have not been tampered with. The proof of the existence of an event generated by the client (mobile application) is represented by the concatenated hash of three components: a description of the event (e.g., a patient requesting an ambulance), its timestamp, and an optional document associated with the event (e.g., a picture of wound, the ID cards of a patient). The resulting hash is stored on the blockchain to guarantee the proof of existence of the event while preserving its integrity and validity. Hash writings and retrievals are performed by the DataHashStorage smart contract deployed on an EVM-compatible blockchain. The contract provides two core functions: (i) storeDataHash(bytes32_dataHash), and (ii) getBlockTimestampFromHash(bytes32_dataHash). The storeDataHash() function takes as input the hash sent by the blockchain module and records it on the blockchain using an internal mapping. This mapping associates each hash with the timestamp of the block in which it was recorded. The block timestamp, represented as a uint256 type in Solidity, is measured in seconds since the Unix epoch. The HEA retrieves the block timestamp from the transaction receipt and associates it with the corresponding data batch in its local database. The getBlockTimestampFromHash() function confirms the presence of a specific hash in the blockchain storage. It takes the hash as input and uses it to query the internal mapping, retrieving the corresponding block timestamp if the hash is found. This timestamp serves as proof of the hash's existence on the blockchain, confirming the associated data's registration. From the block timestamp, the existence of the block and the hash writing transaction can be verified. Conversely, if the function returns the default value of zero, it indicates that the provided hash is not present in the blockchain storage, showing it has not been recorded. Disputes regarding data accuracy may arise when external parties (e.g., patients) report timestamps for critical events (e.g., the arrival time of an ambulance) that differ from those recorded by the system. In these cases, blockchain-stored data hashes are employed to verify the integrity and accuracy of the timestamps. The process involves retrieving the complete incident record from remote cloud storage and computing two hashes: (i) the system-recorded data hash, and (ii) the hash of the data with the disputed timestamp substituted.