## 3 System Architecture of the Decentralized Framework  
### Overview of the Main Components  
Current limitations in healthcare emergency response systems highlight a critical need for effective solutions to certify the authenticity and integrity of events throughout the incident lifecycle. To address this shortcoming, we propose an innovative architecture that integrates blockchain technology to have a secure and transparent mechanism for event certification in emergency response systems. This architecture ensures that critical data related to each incident are certified, fostering trust and accountability in the system. Figure 1 presents a high-level overview of the proposed architecture, outlining the key actors involved and the technologies employed. At the heart of the architecture is the health emergency aggregator (HEA), the main component responsible for managing incidents and triggering the activities necessary to safeguard data integrity. The lifecycle of an incident begins with the emergency call, which yields to the creation of a new incident record. This call goes to the data gateway, a component that acts as a facade and handles all the data from the clients and filters and forwards all the incident data to the HEA, which will store them in a local database. The HEA collects all the data related to an incident until it is resolved and can be archived in the cloud for long-term storage. The HEA functions as a reliable storage system, ensuring that all incident-related data are securely held without undergoing further processing or analysis. This capability provides an accurate historical record of emergency events. To further enhance the security, a mechanism that can demonstrate the authenticity of incident data has been put into place. Critical events identified by the HEA are submitted to the blockchain module, where they are permanently recorded. This blockchain integration allows checking whether stored data were kept unaltered and renders any tampering activities worthless, since it would be easily exposed in case of disputes. The benefit of this approach is twofold: The data are protected from potential tampering, and a transparent audit trail is kept for future reference. Timestamped events are periodically sent to the blockchain while they occur, whereas the analysis of data is performed when needed, much after the incident has been handled, e.g., when further analyses are started to gather statistics on the healthcare service, or to check whether proper activities were performed in due time. The workflow followed by the HEA is presented in Algorithms 1 and 2, which outline a systematic data handling and aggregation. Algorithm 1 shows that payloads received from a data gateway and categorized into one of four types--open, close, ordinary, and critical--trigger specific operations to manage incidents and their associated data. For open payloads, a new incident record is created, having a unique identifier, and then stored. For closed payloads, data related to a specific incident are retrieved and aggregated; then, the results of their management are appended to a list of ordinary data. When processing ordinary and critical payloads, received data are stored; for critical cases, data are immediately aggregated and the results added to a dedicated critical data list. Figure 1: Overview of the proposed architecture, featuring the HEA, data gateway, blockchain integration for secure incident data management, and cloud storage for persistent data storage.