# ODIN IVR-Interactive Solution for Emergency Calls Handling
## 3 Method
### Architecture and Design  
In this section, we present our solution for a chatbot/IVR that can be used in real-life situations, especially in the emergency system. Our proposal identifies non-urgent situations from the emergency call service to prioritize them to fit the hard deadlines. Therefore, we implement the chatbot/IVR solution in the ODIN112 project.  
The solution proposed is a chatbot/IVR module, a component of the ODIN 112 system that could endure during a large-scale emergency following manual activation by an  
\begin{table}
\begin{tabular}{l c c} \hline \hline  & **Performance** & \\ \hline Critical deadline & \textless{}120 s & Beneficiary requirement \\ Emergency handling percentage (SLA) & 99\% & Beneficiary requirement \\ Hardware resources—RAM consumption & \textless{}2 GB & Beneficiary requirement \\ Hardware resources—CPU utilization & \textless{}07\% & Beneficiary requirement \\ Round-trip delay & \textless{}100 ms & [32] \\ Lost rate & \textless{}1\% & [32] \\ Jitter & \textless{}30 ms & [32] \\ Robustness to unexpected input & 91–93\% & [33] \\ \hline \hline  & **Functionality** & \\ \hline Coverage & 95\% & Beneficiary requirement \\ Availability & 24/7 & Beneficiary requirement \\ Input method & text & Beneficiary requirement \\ Output method & audio & Beneficiary requirement \\ Interprets commands accurately & YES & [34] \\ Executes requested tasks & YES & [35] \\ General ease of use & YES & [34] \\ \hline \hline  & **Humanity** & \\ \hline Transparent to inspection (known chatbot/IVR) & YES & [36] \\ Does not have to pass the Turing Test & YES & [35] \\ \hline \hline  & **Satisfaction** & \\ \hline Provides greetings & YES & [37] \\ Protects and respects privacy & YES & [34] \\ \hline \hline \end{tabular}
\end{table}
Table 1: Requirements and specifications of the chatbot/IVR solution.  
authorized administrator, with the automatic pickup of calls that cannot theoretically be answered in 2 min and that asks standard prerecorded questions that only admit simple answers. These scenarios take into account the number of logged-in users at the national level, the average processing time of an urgent call of approximately 60 s or 10 s for a non-urgent call, and a percentage distribution between them that can be configured in the area of administration (e.g., 50%-50%). If the call is classified as a non-urgent situation, it is transferred without the urgent label, and the user receives a web form to fill in the information regarding the non-urgent event. The architecture of the chatbot/IVR solution is presented in Figure 2.  
Moreover, in Figure 2, we show the business logic of the chatbot/IVR solution; it contains two components. The first one is a multi-layer module that identifies the emergency type, namely whether it is a police-related, medical, or fire department emergency. Based on beneficiary requirements, all emergency categories were divided into multiple subcategories, thus resulting in a multi-layer approach. The second component identifies whether the situation is urgent or non-urgent. In both cases, the call is handled by an emergency operator.  
Thus, we propose a lightweight architecture for a chatbot solution that fits the emergency use case derived from the ODIN112 project.  
The chatbot/IVR module is a standalone solution that needs to be integrated into the national emergency system in such a manner that does not affect the quality of the service and does not decrease user satisfaction, especially when users are extremely anxious when facing emergency/critical situations.  
Table 2 presents the main categories of emergencies based on beneficiary requirements, along with their emergency statuses: the \(RED\) status indicates that the situation is urgent and must be treated with high priority; the \(GREEN\) status indicates a non-urgent situation that can be treated in the order of arrival.  
Figure 2: Chatbot/IVR solution business logic flow.