Decentrale Uitgifte FUNCTIONEEL ONTWERP. Naar één voorziening voor het lokaal afhandelen van grote aantallen niet-spoedeisende meldingen

FUNCTIONEEL ONTWERP

Decentrale Uitgifte Naar één voorziening voor het lokaal afhandelen van grote aantallen niet-spoedeisende meldingen

Auteurs: Redactie:

Expertgroep DCU Jan-Willem van Aalst Paul van der Linden Input: Netwerk Meldkamerdomein Landelijk Netwerk Repressie Netwerk Informatiemanagement Eindredactie: Mark Luijten Status: Definitief Versienummer: 1.0 Datum: 15 november 2012

Expertgroep Naam Paul van der Linden Peter Ploeg Theo Roelofs Joop Wessels Koen Gerritsen Bart van Leeuwen Hendrik Jan de Wolf (agenda lid)

Versiebeheer Versie Datum 0.1 2 september 2012 0.2 20 september 2012 0.2.5 25 september 2012 0.3a 18 oktober 2012 1.0 3 november 2012

Regio Brabant-Noord Rotterdam Rijnmond Amsterdam Amstelland Twente Utrecht Amsterdam Amstelland Groningen

Netwerk Meldkamerdomein Meldkamerdomein Meldkamerdomein

Meldkamerdomein

Omschrijving Ter bespreking in expertgroep DCU Ter bespreking in expertgroep DCU, e-mailronde Gereed voor consultatie naar Netwerk Informatiemanagement, Netwerk Meldkamerdomein en Landelijk Netwerk Repressie Ter besluitvorming in Stuurgroep Meldkamerdomein 24-10-2012 Vastgesteld door opdrachtgever 15-11-2012

Document: FO Project: DCU Blad: 2 / 24

Status: Versienummer: Versiedatum:

Definitief 1.0 15 nov. 2012

Inhoudsopgave MANAGEMENTSAMENVATTING....................................................................................................................... 5 1

INLEIDING OP HET FUNCTIONEEL ONTWERP DCU.................................................................................... 7 1.1 1.2 1.3

2

ROLLEN EN GEBRUIKERS DCU................................................................................................................. 10 2.1 2.2 2.3 2.4

3

AANLEIDING ........................................................................................................................................ 7 DEFINITIE VAN FUNCTIONEEL ONTWERP EN FUNCTIONEEL BEHEER...................................................................... 8 SCOPE VAN DIT DOCUMENT ..................................................................................................................... 8

INLEIDING ......................................................................................................................................... 10 POSITIONERING VAN DE DCU IN DE NIEUWE MELDKAMERORGANISATIE ............................................................ 10 ROLLEN ............................................................................................................................................ 10 RECHTEN .......................................................................................................................................... 11

RELATIE MET GMS/NMS FUNCTIONALITEITEN....................................................................................... 14 3.1 INLEIDING ......................................................................................................................................... 14 3.1.1 GMS........................................................................................................................................... 14 3.1.2 NMS........................................................................................................................................... 14

4

FUNCTIONALITEIT TIJDENS INCIDENTEN ................................................................................................ 15 4.1 INLEIDING ......................................................................................................................................... 15 4.2 GENEREREN EN VERSTUREN VAN BERICHT (MELDING) ................................................................................... 15 4.2.1 Uitgangspunt A.1.1 .................................................................................................................... 15 4.2.2 Uitgangspunt A.1.2 .................................................................................................................... 15 4.2.3 Uitgangspunten A.1.3 en A.1.4................................................................................................... 16 4.2.4 Uitgangspunt A.1.5 .................................................................................................................... 16 4.2.5 Uitgangspunt A.1.6 .................................................................................................................... 17 4.3 ONTVANGEN VAN HET VERSTUURDE BERICHT DOOR DE DCU VOORZIENING ....................................................... 17 4.3.1 Uitgangspunten A.2.1 en A.2.2................................................................................................... 17 4.4 INRICHTEN VASTE POST ......................................................................................................................... 17 4.4.1 Uitgangspunten A.3.1 en A.3.2................................................................................................... 17 4.4.2 Uitgangspunt A.3.3 .................................................................................................................... 18 4.5 INCIDENTMANAGEMENT BINNEN DE DCU VOORZIENING ............................................................................... 18 4.5.1 Uitgangspunten B.1.1, B.1.2 en B.1.3.......................................................................................... 18 4.5.2 Uitgangspunten B.2.1 tot en met B.2.10 ..................................................................................... 18 4.5.3 Uitgangspunten B.3.1 en B.3.6 ................................................................................................... 18 4.5.4 Uitgangspunten B.4.1 en B.4.2 ................................................................................................... 19 4.5.5 Uitgangspunten B.5.1 en B.5.2 ................................................................................................... 19 4.5.6 Uitgangspunten B.6.1 en B.6.3 ................................................................................................... 19 4.5.7 Uitgangspunten B.7.1 tot en met B.7.3....................................................................................... 19 4.5.8 Uitgangspunt B.8.1 .................................................................................................................... 19

5

FUNCTIONALITEIT: RAPPORTAGES......................................................................................................... 20




5.1 5.2 5.3

INLEIDING ......................................................................................................................................... 20 RAPPORTAGE FUNCTIONALITEIT IN RELATIE TOT GMS .................................................................................. 20 RAPPORTAGE FUNCTIONALITEIT IN RELATIE TOT NMS .................................................................................. 20

6

BESCHIKBAARHEID................................................................................................................................. 21

7

BEVEILIGING .......................................................................................................................................... 22

8

STANDAARDISATIEKEUZES DCU ............................................................................................................. 23

9

OVERIGE NIET-FUNCTIONELE EISEN ....................................................................................................... 24




Managementsamenvatting Doelstelling en aanbevelingen De Programmaraad Informatiemanagement (PRIM) heeft de volgende doelstelling geformuleerd in de projectopdracht Decentrale Uitgifte (DCU): Verbeter de incidentafhandeling bij grote aantallen niet-spoedeisende meldingen (bij de ‘stormnachtprocedure’ en oudjaarsnacht), door de informatievoorziening tussen meldkamer en uitrukposten te verbeteren. Lever hiertoe concreet op: A. B. C. D.

handreiking voor uniforme werkwijze/werkprocessen voor decentrale uitgifte; programma van eisen voor een uniform ondersteunende voorziening decentrale uitgifte; functioneel ontwerp voor deze voorziening (gebaseerd op het programma van eisen); proof of concept met de voorloperregio’s en leveranciers.

Onderdelen A en B, opgenomen in het Programma van Eisen (PvE) DCU zijn door de expertgroep opgesteld, geconsulteerd bij de NVBR-netwerken Meldkamerdomein, Informatiemanagement en Repressie, en vastgesteld door de Stuurgroep Meldkamerdomein op 28 juli 2012. Het voorliggende Functioneel Ontwerp DCU vormt een logische stap tussen het PVE en een concreet Proof of Concept. De gekozen oplossing dient te passen binnen de door de NVBR geformuleerde richting zoals beschreven in het meerjarenbeleidsplan ‘Informatie Meester’. Eind 2012 begint de pilotfase, het onderzoek moet dan gereed zijn. Strategisch belang In de landelijke beleidsdocumenten “Informatie Meester” en de “Brandweer Informatievoorziening Leidraad – In helder perspectief” (BRIL) wordt nadrukkelijk gestreefd naar landelijke standaardisatie, onder het motto “centraal wat moet, regionaal wat kan”. Belangrijke uitgangspunten daarin zijn:  zorgen voor één gestandaardiseerd uitwisselingsformaat voor gegevens;  meervoudig gebruik van voorzieningen (1x25);  koppelen met ketenpartners via web services;  zoveel mogelijk open standaarden om uitwisselbaarheid van gegevens te verbeteren. Dit sluit aan op uitgangspunten in het programma “Standaardisatie” van de bestuurscommissie IV van het Veiligheidsberaad. Qua beleidslijn kan DCU dus een toekomstbestendige module in het nieuwe NMS worden. Met de resultaten van dit DCU-project van de BVIM kan landelijke functionaliteit worden gedefinieerd, die in pilot-vorm op basis van de huidige GMS-infrastructuur kan worden geïmplementeerd bij die regio’s die wensen dit vóór de ophanden zijnde schaalvergroting van meldkamers te doen. Door zoveel mogelijk gebruik te maken van bestaande ICT-infrastructuur moeten de kosten beperkt blijven. Dit moet uiteindelijk leiden tot een voorziening die in de toekomst deel uitmaakt van de landelijk uniforme blauwdruk van de meldkamerorganisatie. Het belangrijkste doel is uiteraard het verbeteren van de hulpverlening en het verhogen van de veiligheid van de burger. Kernpunten van het Functioneel Ontwerp:  De DCU voorziening is vooralsnog een tijdelijke oplossing, omdat de functionaliteit uiteindelijk integraal onderdeel zal zijn van het nieuwe Nationaal Meldkamer Systeem (NMS).  Elke regio verzorgt een aantal coördinatiepunten/posten waarbij een DCU coördinator de beschikking heeft over de in dit FO beschreven functionaliteit.  De DCU coördinator verzorgt de lokale afhandeling van de niet-spoedeisende meldingen en heeft de mogelijkheid om de resultaten terug te melden richting GMS.




 

De functionaliteit voorziet zowel in koppeling middels een GMS replica-server, alsook in de koppeling via GMS 4.11 waarbij geen replica server meer nodig is. De NMS-DCU versie (DCU versie 2.0) moet een integraal netwerk zijn dat naadloos met elkaar kan communiceren. Meldingen die vanuit NMS naar de DCU voorziening worden doorgezet kunnen in de DCU voorziening worden aangevuld en worden teruggezet naar de meldkamer. Indien nodig, bijvoorbeeld bij een wijziging van de prioriteit, kan de melding door de meldkamer worden teruggehaald naar NMS, bijvoorbeeld om deze melding te kunnen verwerken als een prioriteit 1 melding. Informatie ingevoerd in de DCU voorziening komt ook in de management informatie. Om deze ambities in NMS beschikbaar te hebben bij de eerste release van NMS is het belangrijk om deze eisen tijdig in te brengen bij het opstellen van het FO NMS (eerste helft 2013). Hiertoe is de afstemming met de landelijk projectleider NMS geborgd

Conclusies en aanbevelingen 1. DCU is een voor de regio’s welkome functionaliteit juist in tijden van opschaling van werkgebieden van meldkamers. Het helpt om bij stormnacht, oudjaar en grote evenementen de capaciteit op de meldkamer gebalanceerd beschikbaar te houden voor de echte spoedeisende meldingen. 2. De keuzes voor open standaarden voor berichtenverkeer vergemakkelijken een blijvend goede koppeling tussen DCU/GMS en DCU/NMS. De afstemming met project NMS is geborgd. 3. Aanbeveling: In het laatste kwartaal van 2012 een proof of concept van dit FO uitvoeren met enkele leveranciers (één per regio).




1

Inleiding op het Functioneel Ontwerp DCU

Dit hoofdstuk beschrijft de context waarin dit Functioneel Ontwerp (FO) tot stand is gekomen. Hieronder valt de afbakening (scope) van het onderwerp, de aanleiding (problematiek en resulterende vraagstelling), de geïdentificeerde risico’s en het belang voor de brandweer.

1.1

Aanleiding

Achtergrond Bij schaalvergroting van meldkamers neemt de personeelsomvang relatief gezien af (doordat de verhouding tussen basisbezetting en omvang van het verzorgingsgebied verandert), terwijl het aantal niet-spoedeisende meldingen bij noodweer e.d. relatief gezien gelijk zal blijven. De situatie ontstaat dat in dergelijke omstandigheden mogelijk te weinig personeel beschikbaar is. Dit leidt tot congestie 1 op de meldkamer, wat voor de spoedeisende meldingen onacceptabel is . Er is dan ook behoefte aan slimme oplossingen waarmee grote hoeveelheden niet-spoedeisende meldingen binnen de meldkamer snel kunnen worden verwerkt . In het NVBR/BVIM-project “Decentrale Uitgifte” (DCU) wordt zo’n ‘slimme oplossing’ bedacht en ontworpen, als toekomstbestendige bouwsteen in het nieuwe Nationaal Meldkamersysteem (NMS). Het resultaat komt tot stand met participatie van relevante landelijke partijen/netwerken. Het ministerie van Veiligheid en Justitie (VenJ) heeft een subsidie ter beschikking gesteld om de realisatie van een DCU voorziening te ondersteunen. De DCU voorziening is een relatief kosteneffectieve mogelijkheid om “extra capaciteit” te creëren die rechtstreeks is gekoppeld op NMS, en daarmee te zien als de NMS module om congestie te voorkómen. Strategisch belang en risico’s In de landelijke beleidsdocumenten “Informatie Meester” en de “Brandweer Informatievoorziening Leidraad – In helder perspectief” (BRIL) wordt nadrukkelijk gestreefd naar landelijke standaardisatie, onder het motto “centraal wat moet, regionaal wat kan”. Belangrijke uitgangspunten daarin zijn:  zorgen voor één gestandaardiseerd uitwisselingsformaat voor gegevens;  meervoudig gebruik van voorzieningen (1x25);  koppelen met ketenpartners via web services;  zoveel mogelijk open standaarden om uitwisselbaarheid van gegevens te verbeteren. Dit sluit aan op uitgangspunten in het programma “Standaardisatie” van de bestuurscommissie IV van het Veiligheidsberaad. Qua beleidslijn kan DCU dus een toekomstbestendige module in het nieuwe NMS worden. Met de resultaten van dit DCU-project van de BVIM kan landelijke functionaliteit worden gedefinieerd, die in pilot-vorm op basis van de huidige GMS-infrastructuur kan worden geïmplementeerd bij die regio’s die wensen dit vóór de ophanden zijnde schaalvergroting van meldkamers te doen. Door zoveel mogelijk gebruik te maken van bestaande ICT-infrastructuur moeten de kosten beperkt blijven. Dit moet uiteindelijk leiden tot een voorziening die in de toekomst deel uitmaakt van de landelijk uniforme blauwdruk van de meldkamerorganisatie. Het belangrijkste doel is uiteraard het verbeteren van de hulpverlening en het verhogen van de veiligheid van de burger.

1

Hier is het probleem tweezijdig: 1. veel niet-spoedeisende zaken worden via 112 gemeld, dus die komen als spoedeisend binnen. 2. in al die 112’s zitten ook ‘echte’ spoedeisende meldingen. De uitdaging is om alle 112 binnen de norm aan te nemen en af te handelen.




In lijn met het meerjarenbeleidplan “Informatie Meester” en de door de minister uitgezette beleidslijn uit haar brief uit 20102 wordt aangestuurd op het meervoudig gebruik van ICT-systemen en het standaardiseren van werkprocessen. Het treffen van een centrale voorziening met een centraal beheer lijkt derhalve de meest logische keuze. In het document “Business case DCU” is deze keuze nader onderbouwd. De proof of concept gaat uit van één landelijke set aan DCU functionaliteit, waarop meerdere leveranciers in meerdere regio’s worden getest. Een landelijke aanbesteding voor één leverancier valt buiten de scope van deze fase van DCU. Gebruikte input voor het Functioneel Ontwerp voor DCU De volgende reeds bestaande documenten zijn gebruikt: 1. Business case DCU, opgesteld door Paul van der Linden (Brabant-Noord) in 2011; 2. PvE DCU 1.0, opgesteld door deze expertgroep en vastgesteld door de Stuurgroep Meldkamerdomein op 28 juli 2012; 3. “Eisen aan informatievoorziening Meldkamer Brandweer”, NVBR/ZenC, 30 maart 2011; 4. Het PID DCU 3.7 van de Veiligheidsregio Utrecht, opgesteld door Pagelink; 5. De handleiding van de DCU-voorziening van de Veiligheidsregio Rotterdam-Rijnmond, opgesteld door Peter Ploeg en Pareto; 6. NVBR Meerjarenbeleidsplan “Informatie Meester”, maart 2006; 7. “In helder perspectief”, Brandweer Informatievoorzienig Leidraad (BRIL), november 2007; 8. Brief Minister Ter Horst betreffende Meldkamers in Nederland, 9 februari 2010.

1.2

Definitie van functioneel ontwerp en functioneel beheer

Dit document is het functioneel ontwerp (FO) van de landelijke DCU voorziening. Het beschrijft de functionaliteit die de landelijke voorziening biedt aan gebruikers en beheerders. Als zodanig geldt die beschrijving op landelijk niveau. Op meerdere plaatsen in dit document wordt gesproken over functioneel beheer. Daarmee wordt de configuratie van een regionale DCU voorziening bedoeld in termen van rechten, opties, etc. Die kan per regio verschillen. Waar er verwarring tussen de twee begrippen kan ontstaan, wordt dit in de betreffende alinea expliciet aangegeven.

1.3

Scope van dit document

Dit document beschrijft het Functioneel Ontwerp voor de landelijke voorziening Decentrale Uitgifte (DCU). Dit FO is een BVIM document. Daarbij geldt de volgende scope: In-scope 1. De werkwijze (proces) van het lokaal afhandelen van grote aantallen niet-spoedeisende 3 meldingen ; 2. De wijze waarop meldingen van GMS (en straks NMS) naar een DCU-voorziening worden doorgezet; 3. Het beheren van kenmerken van lokaal af te handelen meldingen, zoals toewijzing van voertuigen en taken; 4. Het beheren van incidenthistorie van lokaal afgehandelde meldingen, t.b.v. leercyclus en managementrapportages.

2

3

www.rijksoverheid.nl/documenten-en-publicaties/persberichten/2010/02/16/ter-horst-wil-een-meldkamer-voor-alle-hulpdiensten.html Zie het Programma van Eisen voor een nadere uitleg van de begrippen “spoedeisend” en “niet-spoedeisend”




Out-of-scope 1. Het geheel van meldkamerprocessen Dit FO gaat niet over het herontwerp van de meldkamerprocessen. De scope begint bij de stap dat een melding wordt geclassificeerd als ‘niet-spoedeisend’. Zie ook het PvE voor een werkprocesschema voor het “DCU” deel. Met de komst van NMS wordt de scope herijkt. 2. Aanpassing van GMS Het geschikt maken van GMS (NMS) om meldingen als elektronische berichten te kunnen verzenden vanuit de GMK (waar nu meerdere software oplossingen voor in omloop zijn) wordt slechts zijdelings belicht. Het project is primair gericht op het inrichten van de DCU voorziening. Uiteraard wordt wel gekeken naar de koppeling met GMS en later NMS, zie hoofdstuk 9. 3. Realisatie van lokaal benodigde voorzieningen Een regio zal zelf lokale voorzieningen moeten inrichten om DCU-meldingen te kunnen ontvangen. De DCU voorziening is een voorziening waarop van elke willekeurige werkplek met een betrouwbare netwerkverbinding kan worden ingelogd; 4. Richting geven aan regionale planvorming Dit is een regionale verantwoordelijkheid. Standaardisatie van werkprocessen is echter wel randvoorwaardelijk voor het kunnen werken met de DCU-voorziening; 5. Meldingen via vaste lijnen Het treffen van maatregelen (zowel procesmatig als technisch) om niet-spoedeisende meldingen niet via het 112-netwerk binnen te laten komen valt buiten de scope van het project DCU. 6. Disciplines in de meldkamer Niet-spoedeisende meldingen spelen vooral in de Brandweer- en Politiemeldkamer. Omdat de huidige opdracht is verstrekt door de Programmaraad IM van de NVBR, is de scope voor dit FO beperkt tot de Brandweer. Verbreding van de scope blijft echter mogelijk.




2 2.1

Rollen en gebruikers DCU Inleiding

De functionele specificatie van “Rollen en Gebruikers” legt de link tussen de meldkamer werkprocessen en het gebruik van de DCU functionaliteit. De DCU voorziening is zo ingericht dat een flexibele configuratie van meerdere beheers- en gebruikersniveaus kan worden gedefinieerd. De voorziening is daarnaast zo ingericht dat de verzorgingsgebieden binnen de voorziening zelf op het niveau van verzorgingsgebied4 op een eenvoudige wijze kunnen worden aangepast.

2.2

Positionering van de DCU in de nieuwe meldkamerorganisatie

Aangezien de DCU integraal onderdeel is van NMS is het een logisch gevolg dat het technisch beheer en het eigenaarschap van de voorziening tezijnertijd ondergebracht worden bij de Landelijke Meldkamer Organisatie (LMO)5 en tot die tijd bij de GMK. De beheersorganisatie levert ondersteuning op administrator niveau en is verantwoordelijk voor de beschikbaarheid van de voorziening. Het Functioneel beheer kan zowel op GMK niveau worden verzorgd als op regionaal niveau. In het laatste geval kunnen er binnen één DCU applicatie dus meerdere functioneel beheerders actief zijn.

2.3

Rollen

We onderscheiden binnen de DCU voorziening de volgende rollen: Rol Administrator Functioneel beheerder

Gebruiker

Bevelvoerende

Monitor (“Lezer”)

Omschrijving De administrator heeft automatisch alle rechten De functioneel beheerder heeft rechten om gebruikers aan te maken, kazernes toe te wijzen aan een gebruiker, verzorgingsgebieden te definiëren, voertuigen aan te maken en instellingen te wijzigen. Een gebruiker (de DCU coördinator) heeft rechten om voor het aan de coördinator toegewezen verzorgingsgebied meldingen in behandeling te nemen, voertuigen aan de melding te koppelen en meldingen af te sluiten. Een bevelvoerende heeft rechten om via mobiel systeem in het ‘veld’ de status van de melding waaraan hij is toegewezen te wijzigen en tekst toe te voegen in het kladblok. Een monitor (lezer, meekijker) heeft rechten om de voortgang van de afhandeling van meldingen in een voor hem gedefinieerd gebied te volgen. Aan de monitor rol zijn uitsluitend leesrechten verbonden.

4

Een regio bepaalt zelf de indeling van verzorgingsgebieden. Vaak zijn dit clusters of districten.

5

De LMO is in ontwerp, en medio/eind 2012 nog geen realiteit.




2.4

Rechten

Aan de in paragraaf 1.2 gedefinieerde rollen dienen rechten te worden toegewezen. Deze paragraaf beschrijft de rechten met de bijbehorende functionaliteit: Actie Configuratie Rechten toewijzen aan rollen Functioneel beheerder toevoegen/ bewerken/ verwijderen Gebruiker toevoegen/bewerken/verwijderen Monitor (lezer) toevoegen/ bewerken/verwijderen Bevelvoerende toevoegen/bewerken/verwijderen

Regio toevoegen / bewerken/verwijderen Vaste post toevoegen/ bewerken/ verwijderen Verzorgingsgebied vaste post definiëren/bewerken Voertuigen aanmaken Voertuigen toewijzen aan een vaste post Unlocken gebruiker Wijzigen wachtwoord Inzet DCU applicatie Aanmaken nieuwe melding Afdrukken van een lopende melding Afdrukken van een melding uit het archief Afsluiten en archiveren melding

Archief met afgesloten meldingen inzien Archief met afgesloten meldingen bewerken Filteren van meldingen Lopende melding bewerken

Functionaliteit De administrator kan op basis van lokale wensen rechten toewijzen Toevoegen, bewerken of verwijderen van één of meerdere functioneel beheerders, bijvoorbeeld bij een interregionale meldkamer Toevoegen, bewerken of verwijderen van gebruikers (DCU coördinatoren) en het toewijzen van het verzorgingsgebied van de vaste post Toevoegen, bewerken of verwijderen van een persoon die de status van lopende melding mag inzien, bijvoorbeeld een coördinerende rol Toevoegen, bewerken of verwijderen van een persoon aan een vaste post die als bevelvoerende de status van een lopende melding kan wijzigen en informatie aan het kladblok kan toevoegen. Toevoegen, bewerken of verwijderen van een gebied met daarin één of meer vaste posten en het toewijzen van vaste posten aan een regio Toevoegen, bewerken of verwijderen van een vaste post Het verzorgingsgebied van een vaste post definiëren Aanmaken van een voertuigen lijst voor een regio Toewijzen van eerstelijns voertuigen aan een vaste post Het vrijgeven van een gebruiker na meerdere onjuiste inloggegevens Het wijzigen van het wachtwoord Het binnen de DCU voorziening aanmaken van een nieuwe melding die buiten de meldkamer om is ontvangen Afdrukken van een lopende melding op een lokale printer Afdrukken van een afgesloten melding uit het archief op een lokale printer, bij voorkeur als PDF Afsluiten en archiveren van een melding. Afsluiten en archiveren is alleen mogelijk als de melding voldoet aan de kenmerken van een verwerkte melding. Er zijn dan geen voertuigen meer gekoppeld en er is een afsluitcode gebruikt. Het raadplegen van het archief met verwerkte meldingen Gegevens in het archief achteraf voorzien van extra informatie Filteren van meldingen op een aantal nader te specificeren criteria Aanvullen van informatie in de melding zoals bijvoorbeeld




Actie

Lopende melding inzien Delen van een lopende melding Delen van een melding uit het archief Melding in behandeling nemen Meldingskarakteristiek toevoegen Opnieuw in behandeling nemen melding Prioriteit wijzigen

Rapportages genereren

Sorteren van meldingen Verversen van het scherm Voertuig potentieel inzien Voertuig (custom voertuig) toevoegen

Voertuigen lenen van een andere vaste post Voertuigen inzetten

Functionaliteit het koppelen van extra voertuigen of het aanvullen van het kladblok In de viewer rol is het mogelijk een lopende melding met een ‘alleen lezen’ autorisatie in te zien Het delen van een lopende melding Het delen van een afgesloten melding Het openen van een binnenkomende melding en deze in behandeling nemen Een melding verder categoriseren Een melding terughalen uit het archief en opnieuw uitgeven De mogelijkheid om prioriteit 2 of 3 aan een melding toe te kennen. In versie 2.0 is het mogelijk om prioriteit 1 aan een melding toe te kennen en deze terug te geven aan de meldkamer Een totaaloverzicht van meldingen in een bepaalde periode genereren. Bij voorkeur in meerdere formats, bijvoorbeeld Excel, CSV en PDF Het sorteren van openstaande meldingen op prioriteit, locatie enz. Geforceerd verversen van het scherm met openstaande meldingen Inzage in de lijst met eigen voertuigen en die van andere vaste posten Een willekeurig voertuig anders dan een basiseenheid koppelen aan een openstaande melding, bijvoorbeeld een PM of een auto van gemeentewerken Uit het beschikbare potentieel van een andere vaste post een voertuig kunnen koppelen aan een openstaande melding Het koppelen en ontkoppelen van een voertuig aan een melding

Functionaliteit Rechten toewijzen aan rollen Functioneel beheerder toevoegen/ bewerken/ verwijderen Gebruiker toevoegen/bewerken/verwijderen Viewer toevoegen/ bewerken/verwijderen Regio toevoegen / bewerken/verwijderen Vaste post toevoegen/ bewerken/ verwijderen Verzorgingsgebied vaste post definiëren/bewerken Voertuigen aanmaken Voertuigen toewijzen aan een vaste post Vrijgeven (“unlock”) gebruiker account Wijzigen wachtwoord Aanmaken nieuwe melding Afdrukken van een lopende melding Afdrukken van een melding uit het archief

Admin

X X X X X X X X X X X X X X

FB

Gebr.

Monitor Bevel(‘lezer’) voerende

X X X X X X X X X X X


X X X

X X



Functionaliteit Afsluiten en archiveren melding Archief met afgesloten meldingen inzien Archief met afgesloten meldingen bewerken Filteren van meldingen Lopende melding bewerken Lopende melding inzien Lopende melding doorsturen Delen van een lopende melding Delen van een melding uit het archief Melding in behandeling nemen Meldingskarakteristiek toevoegen Opnieuw in behandeling nemen melding Prioriteit wijzigen Rapportages genereren Sorteren van meldingen Verversen van het scherm Voertuig potentieel inzien Voertuig (custom voertuig) toevoegen Voertuigen lenen van een andere vaste post Voertuigen inzetten

Admin

FB

Gebr.

X X X X X X X X X X X X X X X X X X X X




Monitor Bevel(‘lezer’) voerende

X X X

X X X

X X X X


X X


3 3.1

Relatie met GMS/NMS functionaliteiten Inleiding

De DCU voorziening is een verlengstuk van het meldkamer systeem. In eerste instantie is er nog sprake van een voorziening die wordt aangestuurd door GMS. In de definitieve variant is de DCU voorziening integraal onderdeel van het NMS netwerk. In dit Functioneel Ontwerp zal voor de GMSDCU voorziening worden gesproken over versie 1.0 en voor de NMS-DCU voorziening over versie 2.0. Bij versie 2.0 is er sprake van een Interregionale DCU voorziening. 3.1.1

GMS

Om versie 1.0 van de DCU voorziening op korte termijn in gebruik te kunnen nemen is het noodzakelijk om het ambitieniveau realistisch te houden. Op dit moment is GMS 4.10 in de meeste Veiligheidsregio’s in gebruik; versie GMS 4.11 is in ontwikkeling (testfase). De nieuwe versie van GMS biedt grote voordelen voor de DCU voorziening, met name het feit dat er geen Replica-server meer nodig is voor de koppeling met GMS. Er zijn vanaf GMS 4.11 voldoende mogelijkheden om direct vanuit een andere applicatie informatie toe te voegen aan een incident; voorwaarde is dan wel dat deze nog ‘actief’ is als de informatie nog bewerkt moet worden6. De ambitie is dan ook om de PoC te testen met zowel de bestaande GMS versie, alsook met de nieuwe 4.11 versie. Meerdere leveranciers/regio’s worden hiertoe uitgenodigd. Vanuit het Brandweer Nederland Programma Meldkamerdomein zullen ook wensen worden ingebracht t.a.v. het jaarplan GMS. Voor 2013 was DCU daar net te laat voor. In 2013 worden de wensen voor 2014 op een rij gezet en geprioriteerd door de stuurgroep Meldkamerdomein. 3.1.2

NMS

In tegenstelling tot de GMS-DCU versie moet de NMS-DCU versie (versie 2.0) een integraal netwerk zijn dat naadloos met elkaar kan communiceren. Meldingen die vanuit NMS naar de DCU voorziening worden doorgezet kunnen in de DCU voorziening worden aangevuld en worden teruggezet naar de meldkamer. Indien nodig, bijvoorbeeld bij een wijziging van de prioriteit, kan de melding door de meldkamer worden teruggehaald naar NMS, bijvoorbeeld om deze melding te kunnen verwerken als een prioriteit 1 melding. Informatie ingevoerd in de DCU voorziening komt ook in de management informatie Om deze ambities in NMS beschikbaar te hebben bij de eerste release van NMS is het belangrijk om deze eisen tijdig in te brengen bij het opstellen van het FO NMS (eerste helft 2013). Hiertoe is de afstemming met de landelijk projectleider NMS geborgd. De tijd is beperkt. Rond mei 2013 moeten de functionele eisen NMS gereed zijn. Het DCU traject houdt daar rekening mee in de eigen planning.

6

Tegelijkertijd wil de meldkamer geen waslijst met openstaande incidenten; dat is voor een centralist (zowel in front- als backoffice) niet werkbaar. Daarnaast is er mogelijk een technische beperking aan het aantal tegelijkertijd openstaande incidenten. Op dit punt wordt tijdens de Proof of Concept nog teruggekomen.




4 4.1

Functionaliteit tijdens incidenten Inleiding

In het FO DCU zijn de eisen opgesteld waaraan de DCU voorziening dient te voldoen. In dit hoofdstuk worden deze eisen verder uitgewerkt. Voor het samenstellen van de DCU melding dient vanuit het meldkamersysteem de volgende informatie te worden verstuurd naar de DCU applicatie:  meldergegevens  adresgegevens (straat, plaats, gemeente en x/y coördinaat)  meldingsclassificatie en karakteristieken  kladblokregels

4.2 4.2.1

Genereren en versturen van bericht (melding) Uitgangspunt A.1.1

De Landelijke Meldingsclassificaties zijn van toepassing op het te genereren bericht (A.1.1) De DCU voorziening wordt aangestuurd door een aantal vooraf te definiëren meldingsclassificaties uit de meest recente LMC set. Naast de meldingsclassificatie dient de DCU voorziening ook meldingskarakteristieken en kladblokregels te ontvangen en presenteren. Vanaf GMS versie 4.11 wordt dit issue eenvoudiger dankzij de directe koppeling. Een regio kan dan ook eigen karakteristieken hebben. NMS: Uitsluitend meldingen geclassificeerd als “niet-spoedeisend” (nu nog vaak geclassificeerd als ‘prio2’ of ‘prio3’) worden verzonden naar de DCU voorziening.7 4.2.2

Uitgangspunt A.1.2

Een bericht is gericht aan één of meerdere decentrale (coördinerende) posten (A.1.2) De DCU voorziening bepaalt op basis van het x/y coördinaat van de melding voor welke kazerne de melding bestemd is. Op functioneel beheerder niveau kunnen meerdere kazernes worden toegewezen aan een coördinerende vaste post, bijvoorbeeld op districts- of clusterniveau; een eenvoudige geografische scheiding zoals (BAG) woonplaats of gemeente is ook toegestaan. Ten behoeve van de algehele coördinatie kunnen meerdere kazernes en/of vaste posten worden toegewezen aan een viewer account. Regio’s worden aangeraden om de autorisatie niet te strak/beperkt in te stellen. Als een voertuig langs een incident rijdt, dit afhandelt en de controlepost van die eenheid er niets mee kan omdat het formeel een andere post is, ontstaan ongewenste situaties. Afscherming per regio is wel begrijpelijk.

7

Hier speelt nog een discussie over of een DCU coördinatiepost in feite neerkomt op een satellietmeldkamer (voor nietspoedeisende meldingen). Dit moet nog nader worden bediscussieerd in de samenwerking met het NMS traject.




Het definiëren van het “dekkingsplan” binnen de DCU voorziening (indeling van verzorgingsgebieden vanuit coördinaatpunten) is door een regio zelf te bepalen. Hiervoor kunnen vaknummers of geografische polygonen zoals gemeenten of districten worden gebruikt (in GIS toepassingen). Als alternatief is ook het gebruik van bestaande Kazerne Volgorde tabellen een optie. Het gaat er om dat een regio een eenduidige verzorgingsdekking heeft gedefinieerd. 4.2.3

Uitgangspunten A.1.3 en A.1.4

Het bericht sluit aan op de bestaande systematiek in GMS en houdt voor zover mogelijk rekening met de eigenschappen van het toekomstige NMS (A.1.3 & A.1.4) Aan de hand van de afsluitcode wordt het export bestand met de noodzakelijke gegevens samengesteld en geëxporteerd naar de DCU applicatie. Het exportbestand is opgemaakt in een bestandsformat in een open gegevensstandaard (zie ook hoofdstuk 8). Vanaf GMS versie 4.11 vervalt dit punt. Het voordeel daarvan is dat het veel kosten kan besparen omdat er niets gewijzigd hoeft te worden in andere backoffice systemen van de Meldkamer Brandweer. In het meldkamersysteem dienen de afsluitcodes te worden gedefinieerd die de melding ontsluiten naar de DCU applicatie. In GMS is dit de afsluitcode ‘Lokaal afhandelen’. De vraag is of deze functionaliteit overbodig is als het uitgangspunt “P3 – P5 is altijd decentraal afhandelen” altijd geldt. Dit is tijdens de uitvoering van de PoC nader te bepalen. Het is noodzakelijk dat in NMS per discipline en per afsluitcode vrij kan worden gedefinieerd hoe een melding kan worden uitgegeven (naar het alarmeringsnetwerk of naar een voorziening voor DCU). 4.2.4

Uitgangspunt A.1.5

De browser wisselt gegevens uit met de voorziening voor decentrale uitgifte middels een beveiligde (versleutelde) verbinding. Bij Internetverkeer volstaat SSL (https://) (A.1.5) Er vanuit gaande dat een DCU melding geen gevoelige informatie bevat kan een melding via een reguliere internetverbinding worden verzonden middels een secure internetverbinding. Het gaat hier om communicatie tussen de (centrale) DCU server en een regulier werkstation op de vaste post. DE communicatie bestaat uit de “B” regels. Uitgegaan moet worden van communicatie met een recente versie van een standaard browser (bewust worden hier geen browsernamen genoemd). DCU kan worden ingericht:  In een gesloten netwerk, bijvoorbeeld het Extranet van de Veiligheidsregio.  Als SaaS-oplossing met een directe koppeling naar de Veiligheidsregio infrastructuur; bij voorkeur niet via Internet maar via een dedicated verbinding. Dit zal echter nog niet in alle regio’s mogelijk zijn. Afhankelijk van hoe ver een veiligheidsregio op dit onderwerp gevorderd is, kiest een regio één van deze opties.




4.2.5

Uitgangspunt A.1.6

Het bericht voor de lokale post bevat voldoende gegevens over de afzender/ maker van het bericht. Welke precies is gespecificeerd in het functioneel ontwerp (A.1.6) In het bericht wordt opgenomen van welke meldkamer werkplek de melding afkomstig is. Het kan hier gaan om het GMS werkstation van de uitgevende meldkamer of de naam van aan het werkstation gekoppelde centralist (voorkeur).

4.3 4.3.1

Ontvangen van het verstuurde bericht door de DCU voorziening Uitgangspunten A.2.1 en A.2.2

Een binnenkomend bericht lokaal af te handelen incident wordt gekoppeld aan de meldkamer die het bericht heeft verstuurd (A.2.1 & A.2.2) De meldkamer van het gebied waar het incident zich voordoet is verantwoordelijk voor de afwikkeling van het incident. De DCU voorziening dient daarom terug te communiceren naar het GMS data warehouse van deze meldkamer en het meldkamersysteem van de uitgevende meldkamer. Dit om te voorkomen dat een melding verloren gaat. Vanaf GMS 4.11 wordt deze functionaliteit eenvoudiger, omdat er een directe koppeling met GMS mogelijk is. In het NMS moet de mogelijkheid bestaan om in de browser van de DCU coördinator handmatig een melding aan te maken die door de DCU voorziening in NMS kan worden ingeschoten. Het gaat hier bijvoorbeeld om meldingen (van eigen ingezette eenheden) die bij een DCU post binnenkomen.

4.4 4.4.1

Inrichten vaste post Uitgangspunten A.3.1 en A.3.2

Qua gebruikersbeheer is een vaste post gelijk aan een groep in een CMS omgeving met bepaalde geautoriseerde gebruikers (A.3.1 & A.3.2) Voor het dagelijkse gebruik van de DCU wordt een rechten/rollen systeem gehanteerd. We gaan hier uit van de volgende rollen:  administrator  functioneel beheerder  gebruiker  bevelvoerende  monitor (lezer) Rol Administrator Functioneel beheerder Gebruiker Bevelvoerende

Omschrijving De administrator rol wordt toegekend aan de met DCU belaste technisch beheerder binnen de GMK De functioneel beheerder is een met de DCU belaste medewerker binnen de GMK of de Veiligheidsregio Een gebruiker is de lokale DCU coördinator van de vaste post Een bevelvoerende heeft rechten om ‘in het veld’ de status van zijn




Monitor (lezer)

4.4.2

voertuig te wijzigen en gegevens aan te vullen in het kladblok Een monitor of lezer is een belanghebbende met een autorisatie om de voortgang in één of meerdere vaste posten te kunnen monitoren

Uitgangspunt A.3.3

De naamgeving van vaste posten heeft een standaard structuur (A.3.3) De naamgeving van de vaste post bestaat uit het volgende format: ##

4.5 4.5.1

Incidentmanagement binnen de DCU voorziening Uitgangspunten B.1.1, B.1.2 en B.1.3

De DCU voorziening is te gebruiken in een browser-omgeving verbonden met een robuuste infrastructuur/verbinding. De operationele rol is leidend bij het toewijzen van rechten voor de beschikbare functionaliteiten (B.1.1, B.1.2 en B.1.3) De DCU voorziening is omwille van het beperken van kwetsbaarheid door overbelasting van het Internet bij voorkeur opgenomen in een besloten Intranet omgeving. De mogelijkheid bestaat om ‘in het veld’ een melding te bewerken door de voertuigstatus te wijzigen en informatie toe te voegen in het kladblok. Het doel van deze functionaliteit is het ontlasten van de vaste post. 4.5.2

Uitgangspunten B.2.1 tot en met B.2.10

De DCU voorziening is te bedienen met een zeer eenvoudige interface (B.2.1 tot en met B.2.10) De gebruikersinterface biedt de gebruiker en de bevelvoerende de mogelijkheid om een melding in behandeling te nemen en te bewerken. De interface bestaat uit een duidelijke lay-out met niet meer informatie dan strikt noodzakelijk is voor het kunnen verwerken van de melding. Omdat de DCU ook door een bevelvoerende op een mobiel apparaat moet kunnen worden bediend, dienen knoppen in de DCU tool niet te klein worden uitgevoerd. 4.5.3

Uitgangspunten B.3.1 en B.3.6

In de DCU voorziening is het mogelijk om in de gebruikers en bevelvoerende modus voertuigen uit een voertuigenlijst aan een melding te koppelen en hieraan verschillende statussen toe te wijzen. Het is eveneens mogelijk om custom voertuigen in te voeren. (B.3.1 & B.3.2) De DCU coördinator kan voertuigen koppelen uit een voertuigenlijst van de aan zijn vaste post toegewezen voertuigen. Tevens kan hij custom voertuigen invoeren en aan een melding koppelen, bijvoorbeeld ten behoeve van het inzetten van zaagploegen van de gemeente of tweedelijns voertuigen. Tevens kan hij vanuit een bestand voertuigen importeren die niet primair aan zijn vaste post zijn toegewezen.




4.5.4


In de DCU voorziening is het mogelijk de status van voertuigen aan te passen (B.4.1 & B.4.2 Een DCU coördinator kan de status van een voertuig wijzigen. Indien de status vrij is toegekend aan een voertuig is het voertuig weer beschikbaar voor andere meldingen. De statusmelding in de DCU voorziening is niet van invloed op de statusmelding in GMS/NMS. Een bevelvoerende kan vanuit het voertuig zijn eenheid vrijgeven voor een nieuwe melding. 4.5.5


Het is mogelijk om in de DCU voorziening een melding te her prioriteren (B.5.1 & B.5.2) Het is voor de DCU coördinator mogelijk om binnen de door hem af te werken niet spoedeisende meldingen een eigen prioriteit aan te geven. 4.5.6


In de DCU voorziening kan de gebruiker de taken en takenlijsten beheren (B.6.1 tot en met B.6.3) Taken kunnen worden toegevoegd, bewerkt, verwijderd en geëxporteerd ten behoeve van management rapportages. Takenlijsten worden automatisch of handmatig ververst. 4.5.7

Uitgangspunten B.7.1 tot en met B.7.3

In de DCU voorziening is het mogelijk de vanuit GMS/NMS meegezonden kladblok informatie te wijzigen (B.7.1 tot en met B.7.2) Informatie in het kladblok is door de DCU coördinator of door de bevelvoerende te lezen, aan te vullen of te verwijderen, bijvoorbeeld met aanvullende informatie, bijzonderheden en/of vervolgafspraken. 4.5.8

Uitgangspunt B.8.1

Het is mogelijk het incident te printen (B.8.1) Het is mogelijk om het incident, inclusief de kladblokregels te printen op een lokale printer. Overige onderwerpen zijn als eisen opgenomen in het document PvE DCU, teneinde dubbele specificaties te vermijden.




5 5.1

Functionaliteit: rapportages Inleiding

Een grote tekortkoming van de meeste oplossingen die op dit moment worden gebruikt voor het lokaal afhandelen van niet-spoedeisende meldingen is het ontbreken van een goede mogelijkheid om managementrapportages te kunnen genereren na bijvoorbeeld een situatie met extreme weersomstandigheden. Als een melding uit GMS is uitgegeven is het voor de meldkamer niet meer mogelijk hier nog informatie aan toe te voegen. Hierdoor ontbreekt een totaalbeeld van de situatie die het lokaal afhandelen van meldingen noodzakelijk maakte.

5.2

Rapportage functionaliteit in relatie tot GMS

Een belangrijke functionaliteit van de DCU voorziening is een mogelijkheid tot het genereren van managementrapportages. Hiervoor is het noodzakelijk dat de DCU informatie terug kan sturen naar de datawarehouse waar ook de GMS rapportages worden opgeslagen (Uitgangspunt C.3.1 tot en met C.3.2 en C.3.4 uit het PvE DCU). In de ideale situatie is het mogelijk om de in GMS aangemaakte melding samen te voegen met een uit de DCU voorziening afkomstige melding. Het is wenselijk om dubbele entries in het datawarehouse te voorkomen. Het GMS incidentnummer wordt daarom in de DCU voorziening overgenomen waarmee de melding is voorzien van een uniek ID.

5.3

Rapportage functionaliteit in relatie tot NMS

De ambitie is om de DCU voorziening integraal onderdeel te laten worden van het NMS netwerk. De DCU voorziening kan een terugmeldbericht genereren dat leesbaar is voor NMS bij een incident waarbij de prioriteit is opgehoogd en de noodzaak bestaat dat het incident door de meldkamer opnieuw in behandeling wordt genomen. (Uitgangspunt C.3.3 en C.3.5 uit het PvE) Overige zaken zijn als eisen opgenomen in het document PvE DCU, teneinde dubbele specificaties te vermijden.




6

Beschikbaarheid

De beschikbaarheid van de DCU-voorziening dient volgend te zijn aan de beschikbaarheid van alle gekoppelde systemen. De DCU-voorziening is afhankelijk van GMS en de beschikbaarheid van internet/intranet/veiligheidsnet. Hiervoor moet zorgvuldig wordt gekeken naar de implementatie in het meldkamer-/ of veiligheidsdomein, zodat onderlinge uitwisseling van gegevens zonder vertraging kan worden gerealiseerd, terwijl de uitwisseling met de locaties binnen het domein, maar buiten de fysieke meldkamer, zo soepel mogelijk moet zijn. Beschikbaarheid van de DCU-voorziening is dubbel uitgevoerd (D 3.2). Hierdoor is de realisatie van 99,0 % beschikbaarheid reëel. Gegarandeerde beschikbaarheid dient te worden ondersteund door afdeling Lokaal Beheer van meldkamerdomein. De ervaring leert dat juist in crisissituaties de beschikbaarheid van de DCU-voorziening onder druk staat. Overige zaken zijn als eisen opgenomen in het reeds vastgestelde document PvE DCU, teneinde dubbele specificaties te vermijden.




7

Beveiliging

De DCU voorziening staat of valt met een goede beveiliging van gegevens en beveiliging van toegang tot gegevens. De applicatie draait in een afgeschermde omgeving. De eisen die aan deze omgeving worden gesteld, staan reeds beschreven in het eerder gepubliceerde document PvE DCU, verkrijgbaar bij de NVBR/BVIM. Het verdient aanbeveling om binnen de applicatie zo weinig mogelijk onderscheid te maken in rechten. Het gaat om het ongecompliceerd werken in een crisisomgeving, waarin soms meerdere taken bij dezelfde personen komen te liggen. (Uiteindelijk zouden personen geïdentificeerd moeten kunnen worden via een regiobrede Active Directory, zodat er maar één keer moet worden ingelogd. Dit is echter voor veel regio’s toekomstmuziek. Een alternatief is om de autorisatie te regelen via de GMS autorisatie. Met de komst van NMS krijgt het rechtenvraagstuk (autorisatie) wederom een nieuwe dimensie. Meldkamers worden samengevoegd; er komt mogelijk een landelijke active directory. Dergelijke ontwikkelingen zijn niet nu al op te nemen in het FO (anders kan een leverancier geen Proof of Concept uitvoeren), maar worden wel afgestemd met de kwartiermaker NMS. Overige zaken zijn als eisen opgenomen in het reeds vastgestelde document PvE DCU, teneinde dubbele specificaties te vermijden.




8

Standaardisatiekeuzes DCU

Om op de toekomst voorbereid te zijn, en dat is een van de doelen gezien de expleciete benoeming van NMS, is het belangrijk om na te denken over een stuk standaardisatie binnen de DCU voorziening, en standaardisatie van de DCU voorziening in relatie tot haar directe omgeving, met name koppelingen met het huidige GMS en later met NMS. Het eerste houvast hiervoor is de VeRA 1.0 waar duidelijk aanwijzingen genoemd zijn mbt koppel vlakken data modellen. Deze worden in VeRA 2.0 concreter ingevuld; echter VeRA 2.0 is pas medio 2013 gereed. Het project DCU kan tot die tijd dus slechts beperkt keuzes maken. Daarnaast moet er ook goed gekeken worden naar de aard van de meldingen die met de DCU afgehandeld dienen te worden, in relatie tot de landelijk vastgestelde Meldingsclassificaties. Toelichting op relatie met VeRA 1.0 In VeRA 1.0 wordt uitdrukkelijk gesproken over een flexibel datamodel, in combinatie met de semantiek van de data zelf. Dit betekent dat een datamodel gebruikt moet worden dat het liefst beide eisen direct oppakt. Het Resource Description Framework (RDF), een standaard van het W3C comité biedt exact dat: een flexibel model zonder vast schema waarbij de metadata direct in de data is opgenomen. Dit semantische model is ook benoemd in onder andere het Europese INSPIRE programma, voor het vastleggen en benoemen van object in de openbare ruimte. De serialisatie van RDF kan volgens de nu geldende standaard van het W3c geschieden in het (voor programmeurs) goed leesbare Turtle of RDF/XML. Er zijn reeds vocabulaires aanwezig om de belangrijkste elementen binnen uitruk berichten als RDF uit te drukken. Deze keuze zorgt naar verwachting voor een zo optimaal mogelijke koppelbaarheid met zowel het huidige GMS als het nieuwe NMS. Via de landelijke projectleider NMS vindt afstemming plaats over de ontwerpkeuzes die in het NMS traject worden gemaakt. Toelichting op de relevantie van de aard van de meldingen “Koude Ketenpartners” zoals gemeenten spelen een belangrijke rol in het volledig afhandelen van het incident, Aangezien de meldingen voornamelijk niet spoedeisend van aard zijn, zal in veel gevallen het totaal afronden van een melding nog bij een andere partij liggen, denk hierbij aan een omgevallen boom bij storm, of een uitgebrande hoop vuil tijdens oud en nieuw. De brandweer is primair niet verantwoordelijk voor het opruimen hiervan, alleen voor het stabiliseren. De DCU moet derhalve een mogelijkheid hebben om een melding integraal door te zetten richting de gemeente nadat de situatie gestabiliseerd is, eventueel direct door de bevelvoerder vanuit het voertuig. Diensten als Verbeter de buurt en Buiten beter maken van zo'n aansluiting gebruik. Dit draagt er aan bij dat het incident tot aan het opruimen toe vanuit de DCU behandeld kan worden.




9

Overige niet-functionele eisen

[Input vanuit Netwerk Meldkamerdomein, Netwerk Informatiemanagement en Landelijk Netwerk Repressie hier]




Decentrale Uitgifte FUNCTIONEEL ONTWERP. Naar één voorziening voor het lokaal afhandelen van grote aantallen niet-spoedeisende meldingen

Recommend Documents