911/112 :un modèle de données de service d'appel d'urgence

Appeler un numéro d'urgence comme le 911 ou le 112 n'est pas quelque chose que nous attendons avec impatience, mais nous sommes heureux de l'avoir quand nous en avons besoin ! À l'autre bout de la ligne, c'est un travail stressant et il y a peu de place pour les erreurs. Tout doit fonctionner parfaitement.

Aujourd'hui, nous allons examiner le modèle de données qu'un service d'urgence pourrait utiliser pour traiter et répondre aux appels entrants.

Idée

Les numéros d'urgence diffèrent d'un pays à l'autre. Les numéros 911 (Amérique du Nord et certains autres pays) et 112 (Europe et certaines parties de l'Afrique et de l'Asie) sont largement utilisés. Ces numéros sont utilisés pour contacter les trois services d'urgence (police, ambulance et pompiers et secours) en un seul appel. Certains pays utilisent un numéro différent; d'autres n'ont pas de numéro d'urgence centralisé. Dans ce modèle, je vais me concentrer sur les situations où un tel numéro centralisé existe.

L'idée principale est que lorsque quelqu'un passe un appel, un opérateur s'occupe de cet appel, collecte toutes les informations pertinentes et transmet ces informations aux responsables. Un exemple pourrait être un accident de voiture :après avoir reçu l'appel, l'opérateur doit savoir où cet accident s'est produit et quelle est sa gravité. Ils peuvent alors envoyer la police et une ambulance pour gérer la situation. Un autre exemple pourrait être un incendie dans un immeuble d'habitation, qui pourrait nécessiter les trois services d'urgence.

Modèle de données

Le modèle de données se compose de trois domaines :

Countries & cities
Calls
Actions & services

Nous décrirons chacun de ces domaines dans l'ordre dans lequel ils sont répertoriés.

Pays et villes

Ce domaine n'est pas spécifique à ce modèle, mais il est toujours nécessaire pour suivre les emplacements d'où proviennent les appels.

Nous n'avons que deux tables dans ce domaine. Le country table contient une liste UNIQUE de country_name valeurs. Nous pouvons nous attendre à n'avoir qu'un seul pays ici, car les services d'urgence fonctionnent principalement au niveau national. Dans un pays plus grand, cette table pourrait être utilisée pour stocker des noms d'état ou de province.

Une liste de toutes les villes et villages est stockée dans le city dictionnaire. Pour chaque ville, nous stockerons une combinaison UNIQUE de country_id - city_name . Nous pouvons nous attendre à ce que ce tableau contienne une liste de toutes les villes et villages d'un certain pays.

Appels

Deux domaines sont spécifiques à ce modèle de données :Calls et Actions & services . Dans le cours du temps, les appels viennent en premier et déclenchent d'autres événements. Par conséquent, nous allons d'abord décrire cette section.

Les Calls domaine est composé de cinq tableaux. Pendant que l'call table est évidemment la table centrale, nous décrirons d'abord les quatre autres tables car elles sont toutes référencées dans la table d'appel.

Les utilisateurs lancent des appels à l'aide de leur téléphone fixe ou mobile. Nous devons stocker chaque numéro qui a appelé le 112 ou le 911, nous aurons donc besoin d'un phone_number table. Chaque fois qu'un nouvel appel est lancé, nous vérifions si le numéro existe déjà dans ce tableau. Sinon, nous insérerons une nouvelle ligne. Pour chaque enregistrement de table, nous stockerons :

phone_number – Le numéro qui a initié un appel.
number_status_id – Une référence au number_status dictionnaire. Cette valeur doit indiquer si le numéro a effectué le "premier contact", est "sur liste noire" ou "bloqué", etc. Cette valeur pourrait nous aider à décider quoi faire, par ex. ne pas créer de nouvel appel si un numéro est bloqué, lancer un avertissement si un numéro est sur liste noire ou simplement enregistrer des informations pour l'opérateur.
notes – Toutes les notes liées à ce numéro, insérées par n'importe quel opérateur. Ce champ n'est pas obligatoire et contiendra principalement des valeurs NULL.

L'operator table est utilisée pour stocker une liste de tous les opérateurs qui reçoivent des appels. Pour chaque opérateur, nous stockerons un operator_code UNIQUE (une désignation interne), le first_name de l'opérateur , et leur last_name . Nous ne stockerons pas de détails ici, comme les coordonnées des opérateurs ou un indicateur indiquant si l'opérateur est actuellement occupé ou non.

Pour chaque appel, nous voulons attribuer un certain statut. Pour ce faire, nous aurons d'abord besoin d'un call_status dictionnaire. Ce dictionnaire contient un ensemble de status_name UNIQUES valeurs. Certaines valeurs attendues sont :"appel interrompu", "appel abandonné", "appel réussi" et "appel réacheminé".

Nous sommes maintenant prêts à décrire l'call table. Un appel est lancé par l'appelant. Une fois le numéro inséré dans la base de données (s'il s'agit d'un numéro précédemment inconnu), l'appel est également inséré. Pour chaque appel, nous devrons stocker :

operator_id – Une référence au operator qui a reçu cet appel.
phone_number_id – Le numéro qui a passé l'appel. Dans presque tous les cas, cet attribut contiendra une valeur faisant référence au phone_number table. Pourtant, j'ai laissé une option pour insérer un appel sans numéro de téléphone. Cela peut se produire lorsqu'un numéro est masqué ou en cas d'erreur de réseau.
call_status_id – Une référence au call_status dictionnaire qui décrit le résultat de l'appel. Cette valeur sera insérée à la fin de l'appel.
city_id – Une référence à la city dictionnaire, désignant la ville où l'appel a été effectué. Cela peut également être NULL, car cette information peut être inconnue ou inutile.
call_start_time – Indique quand l'appel a commencé. Il peut être NULL dans certains cas particuliers, par ex. l'opératrice a entendu la ligne sonner, mais l'appel n'a jamais été établi.
call_end_time – Lorsque l'appel est terminé. Cette valeur sera mise à jour à l'heure réelle de la fin de l'appel. Il contiendra une valeur NULL si l'appel n'a jamais démarré ou si l'appel a démarré mais est toujours en cours.
notes – Toutes les notes, en format texte libre, que l'opérateur a insérées concernant cet appel.

Actions et Services

Après un appel, il est temps d'agir. Ces actions doivent alerter automatiquement les services d'urgence requis ; nous devrions également pouvoir insérer ou supprimer des alertes selon les besoins.

Pour couvrir cela, nous utiliserons cinq tables supplémentaires.

Dans le emergency_service table, nous stockerons une liste de tous les services d'urgence disponibles. Cette table contient un service_name UNIQUE et toute information nécessaire pour établir un contact. Les informations de contact sont stockées dans un format structuré de type JSON dans le contact_details attribut. Certains des services d'urgence attendus sont la «police», les «pompiers» et «l'ambulance». Pourtant, nous pourrions en avoir d'autres aussi, comme "secours en montagne", "garde civile", etc.

Le action_catalog dictionnaire contient une liste de toutes les actions possibles qui pourraient être requises à la suite d'un appel. Cette table contient une liste de tels action_name UNIQUES valeurs. Certaines valeurs attendues ici sont "alerter tous les services", "alerte ambulance", etc.

Nous devons maintenant définir une liste de toutes les alertes qui doivent se produire automatiquement lorsqu'une action est attribuée à un appel. Ces valeurs sont stockées dans le alert_service table. Nous stockerons la paire UNIQUE action_catalog_id – emergency_service_id , indiquant qu'un certain service d'urgence doit être contacté lorsque cette action est assignée. Pourtant, parfois, nous pourrions vouloir réviser cela, donc je vais laisser une option pour le faire. Si le drapeau always_alert est défini sur Vrai, nous enverrons cette alerte sans supervision manuelle ; sinon, l'opérateur peut intervenir.

L'attribution d'une action à un appel se fait via le action_required table. Nous pouvons avoir besoin de plus d'une action pour chaque appel, nous avons donc besoin de ce tableau. Nous stockerons la combinaison UNIQUE call_id – action_id ainsi que les éventuelles notes insérées par l'opérateur.

La dernière table de notre modèle est le alerted_service table. Paires UNIQUES de action_required_id – emergency_service_id indiquent les alertes réelles qui ont été lancées pour cette action (et cet appel). Ce seront tous les enregistrements avec le alert_service.always_alert défini sur Vrai et toutes les alertes définies manuellement après que l'opérateur les a révisées.

Améliorations possibles

Ce modèle n'est que l'épine dorsale d'une solution possible. Je peux personnellement suggérer de nombreuses améliorations :

Comment les données des opérateurs sont stockées.
Y compris la possibilité de suivre ce qui s'est passé après que les services d'urgence ont été alertés.
Laisser un opérateur lancer un appel.
Relier les événements dans la base de données afin que nous puissions définir si un certain appel était lié à un autre appel, action ou alerte. Pour le moment, nous ne connaissons que leur commande.

Comment fonctionnent ces services dans votre pays ? Avons-nous raté quelque chose ? Que voudriez-vous ajouter ou supprimer de ce modèle ? Veuillez nous le dire dans les commentaires ci-dessous.