911/112:En nödsamtalstjänstdatamodell

Att ringa ett nödnummer som 911 eller 112 är inget vi ser fram emot, men vi är glada över att ha det när vi behöver det! I andra änden av linjen är det ett stressigt jobb och det finns lite utrymme för misstag. Allt måste fungera perfekt.

Idag ska vi ta en titt på datamodellen en räddningstjänst kan använda för att behandla och svara på inkommande samtal.

Idé

Nödnummer skiljer sig från land till land. Siffrorna 911 (Nordamerika och vissa andra länder) och 112 (Europa och delar av Afrika och Asien) används ofta. Dessa nummer används för att kontakta alla tre räddningstjänsten (polis, ambulans och brand och räddning) i ett samtal. Vissa länder använder ett annat nummer; andra har inte ett centraliserat larmnummer. I den här modellen kommer jag att fokusera på situationer där ett sådant centraliserat nummer finns.

Huvudtanken är att när någon ringer tar en operatör hand om samtalet, samlar in all relevant information och vidarebefordrar denna information till de ansvariga. Ett exempel kan en bilolycka:efter att ha tagit emot samtalet ska operatören veta var olyckan inträffade och hur allvarlig den är. De kan då skicka polis och ambulans för att hantera situationen. Ett annat exempel kan vara en brand i ett flerfamiljshus som kan kräva alla tre räddningstjänsten.

Datamodell

Datamodellen består av tre ämnesområden:

• Länder och städer
• Samtal
• Åtgärder och tjänster

Vi kommer att beskriva vart och ett av dessa ämnesområden i den ordning de är listade.

Länder och städer

Det här ämnesområdet är inte specifikt för den här modellen, men det behövs fortfarande för att spåra platserna där samtal kom ifrån.

Vi har bara två tabeller inom detta ämnesområde. landet Tabellen innehåller en lista med UNIKT country_name värden. Vi kan förvänta oss att vi bara kommer att ha ett land här eftersom räddningstjänsten mestadels fungerar på nationell nivå. I ett större land kan den här tabellen användas för att lagra namn på delstater eller provinser.

En lista över alla städer och byar lagras i stad lexikon. För varje stad kommer vi att lagra en UNIK kombination av country_id - stadsnamn . Vi kan förvänta oss att denna tabell kommer att innehålla en lista över alla städer och byar i ett visst land.

Samtal

Det finns två ämnesområden som är specifika för denna datamodell:Samtal och Åtgärder och tjänster . I strömmen av tiden kommer samtal först och utlöser andra händelser. Därför kommer vi att beskriva det här avsnittet först.

Samtalen ämnesområdet består av fem tabeller. Medan samtal tabellen är uppenbarligen den centrala, vi kommer att beskriva de andra fyra tabellerna först eftersom de alla refereras till i samtalstabellen.

Användare initierar samtal med sina fasta telefoner eller mobiltelefoner. Vi måste lagra varje nummer som ringde 112 eller 911, så vi behöver ett telefonnummer tabell. Varje gång ett nytt samtal initieras kontrollerar vi om numret redan finns i den här tabellen. Om inte, infogar vi en ny rad. För varje tabellpost lagrar vi:

• telefonnummer – Numret som initierade ett samtal.
• nummer_status_id – En referens till number_status lexikon. Detta värde ska ange om numret som gjordes till den "första kontakten", är "svartlistat" eller "blockerat", etc. Detta värde kan hjälpa oss att bestämma vad vi ska göra, t.ex. att inte skapa ett nytt samtal om ett nummer är blockerat, slänga ut en varning om ett nummer är svartlistat eller helt enkelt spela in information för operatören.
• anteckningar – Alla anteckningar relaterade till det numret, infogade av valfri operatör. Detta är inte ett obligatoriskt fält och kommer oftast att innehålla NULL-värden.

operatören Tabell används för att lagra en lista över alla operatörer som tar emot samtal. För varje operatör lagrar vi en UNIK operatörskod (en intern beteckning), operatörens first_name , och deras efternamn . Vi kommer inte att lagra information här, som operatörernas kontaktuppgifter eller en flagga som anger om operatören för närvarande är upptagen eller inte.

För varje samtal vill vi tilldela en viss status. För att göra det behöver vi först en call_status lexikon. Denna ordbok innehåller en uppsättning UNIK status_name värden. Några förväntade värden är:"samtal avbrutet", "samtal avbröts", "lyckat samtal" och "samtal omdirigeras".

Nu är vi redo att beskriva samtal tabell. Ett samtal initieras av den som ringer. Efter att numret har infogats i databasen (om det är ett tidigare okänt nummer) infogas även samtalet. För varje samtal måste vi lagra:

• operatörs-id – En referens till operatören som tog emot det här samtalet.
• telefonnummer_id – Numret som ringde. I nästan alla fall kommer detta attribut att innehålla ett värde som hänvisar till phone_number tabell. Ändå lämnade jag ett alternativ att lägga in ett samtal utan telefonnummer. Detta kan hända när ett nummer är dolt eller om det finns något slags nätverksfel.
• call_status_id – En referens till call_status ordbok som beskriver samtalsresultatet. Detta värde kommer att infogas i slutet av samtalet.
• stads-id – En referens till staden ordbok, som anger staden där samtalet gjordes. Detta kan också vara NULL, eftersom denna information kan vara okänd eller onödig.
• samtal_starttid – Anger när samtalet startade. Den kan vara NULL i vissa speciella fall, t.ex. operatören hörde linjen ringa, men samtalet upprättades aldrig.
• samtal_sluttid – När samtalet avslutades. Detta värde kommer att uppdateras vid den faktiska tidpunkten då samtalet avslutas. Det kommer att innehålla ett NULL-värde om samtalet aldrig startade, eller om samtalet startade men fortfarande pågår.
• anteckningar – Alla anteckningar, i fritextformat, som operatören infogat angående detta samtal.

Åtgärder och tjänster

Efter ett samtal är det dags för åtgärder. Dessa åtgärder bör automatiskt varna nödvändiga räddningstjänster; vi bör också kunna infoga eller ta bort varningar efter behov.

För att täcka detta kommer vi att använda ytterligare fem tabeller.

I emergency_service tabell lagrar vi en lista över alla tillgängliga räddningstjänster. Den här tabellen innehåller ett UNIKT tjänstnamn och all information som behövs för att upprätta en kontakt. Kontaktinformation lagras i ett strukturerat JSON-liknande format i contact_details attribut. Några av de förväntade räddningstjänsterna är "polis", "brandkår" och "ambulans". Ändå skulle vi kunna ha andra också, som "bergräddning", "civilvakt", etc.

action_catalog ordboken innehåller en lista över alla möjliga åtgärder som kan krävas som ett resultat av ett samtal. Den här tabellen innehåller en lista över sådana UNIKA action_name värden. Några förväntade värden här är "larma alla tjänster", "larma ambulans" etc.

Nu måste vi definiera en lista över alla varningar som ska ske automatiskt när en åtgärd tilldelas ett samtal. Dessa värden lagras i alert_service tabell. Vi lagrar det UNIKA paret action_catalog_id – emergency_service_id , vilket anger att en viss jourtjänst ska kontaktas när denna åtgärd tilldelas. Ändå, ibland kanske vi vill revidera detta, så jag lämnar ett alternativ att göra det. Om flaggan always_alert är inställd på True, skickar vi denna varning utan manuell övervakning; annars kan operatören ingripa.

Att tilldela en åtgärd till ett samtal görs via action_required tabell. Vi kan behöva ha mer än en åtgärd för varje samtal, så vi behöver den här tabellen. Vi lagrar den UNIKA kombinationen call_id – action_id samt eventuella anteckningar som infogats av operatören.

Den sista tabellen i vår modell är alerted_service tabell. UNIKA par av action_required_id – emergency_service_id beteckna de faktiska varningarna som initierades för den åtgärden (och anropet). Dessa kommer att vara alla poster med alert_service.always_alert inställd på True och alla varningar ställs in manuellt efter att operatören ändrat dem.

Möjliga förbättringar

Denna modell är bara ryggraden i en möjlig lösning. Jag kan personligen föreslå många förbättringar:

• Hur operatörernas data lagras.
• Inklusive möjligheten att spåra vad som hände efter att räddningstjänsten larmades.
• Låta en operatör initiera ett samtal.
• Relaterar händelser i databasen så att vi kan definiera om ett visst samtal var relaterat till ett annat samtal, åtgärd eller varning. För närvarande känner vi bara till deras beställning.

Hur fungerar sådana tjänster i ditt land? Har vi missat något? Vad skulle du lägga till eller ta bort från den här modellen? Berätta för oss i kommentarerna nedan.