FUNCTIONEEL ONTWERP Decentrale Uitgifte Naar één voorziening voor het lokaal afhandelen van grote aantallen niet-spoedeisende meldingen Auteurs: Redactie: Input: Expertgroep DCU Jan-Willem van Aalst Paul van der Linden Netwerk Meldkamerdomein Landelijk Netwerk Repressie Netwerk Informatiemanagement Mark Luijten Definitief Eindredactie: Status: Versienummer: 1.0 Datum: 15 november 2012
Expertgroep Naam Regio Netwerk Paul van der Linden Brabant-Noord Meldkamerdomein Peter Ploeg Rotterdam Rijnmond Theo Roelofs Amsterdam Amstelland Meldkamerdomein Joop Wessels Twente Meldkamerdomein Koen Gerritsen Utrecht Bart van Leeuwen Amsterdam Amstelland Hendrik Jan de Wolf (agenda lid) Groningen Meldkamerdomein Versiebeheer Versie Datum Omschrijving 0.1 2 september 2012 Ter bespreking in expertgroep DCU 0.2 20 september Ter bespreking in expertgroep DCU, e-mailronde 2012 0.2.5 25 september 2012 Gereed voor consultatie naar Netwerk Informatiemanagement, Netwerk Meldkamerdomein en Landelijk Netwerk Repressie 0.3a 18 oktober 2012 Ter besluitvorming in Stuurgroep Meldkamerdomein 24-10-2012 1.0 3 november 2012 Vastgesteld door opdrachtgever 15-11-2012 Blad: 2 / 24 Versiedatum: 15 nov. 2012
Inhoudsopgave MANAGEMENTSAMENVATTING... 5 1 INLEIDING OP HET FUNCTIONEEL ONTWERP DCU... 7 1.1 AANLEIDING... 7 1.2 DEFINITIE VAN FUNCTIONEEL ONTWERP EN FUNCTIONEEL BEHEER... 8 1.3 SCOPE VAN DIT DOCUMENT... 8 2 ROLLEN EN GEBRUIKERS DCU... 10 2.1 INLEIDING... 10 2.2 POSITIONERING VAN DE DCU IN DE NIEUWE MELDKAMERORGANISATIE... 10 2.3 ROLLEN... 10 2.4 RECHTEN... 11 3 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 Blad: 3 / 24 Versiedatum: 15 nov. 2012
5.1 INLEIDING... 20 5.2 RAPPORTAGE FUNCTIONALITEIT IN RELATIE TOT GMS... 20 5.3 RAPPORTAGE FUNCTIONALITEIT IN RELATIE TOT NMS... 20 6 BESCHIKBAARHEID... 21 7 BEVEILIGING... 22 8 STANDAARDISATIEKEUZES DCU... 23 9 OVERIGE NIET-FUNCTIONELE EISEN... 24 Blad: 4 / 24 Versiedatum: 15 nov. 2012
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. handreiking voor uniforme werkwijze/werkprocessen voor decentrale uitgifte; B. programma van eisen voor een uniform ondersteunende voorziening decentrale uitgifte; C. functioneel ontwerp voor deze voorziening (gebaseerd op het programma van eisen); D. 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. Blad: 5 / 24 Versiedatum: 15 nov. 2012
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). Blad: 6 / 24 Versiedatum: 15 nov. 2012
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 op de meldkamer, wat voor de spoedeisende meldingen onacceptabel is 1. 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. Blad: 7 / 24 Versiedatum: 15 nov. 2012
In lijn met het meerjarenbeleidplan Informatie Meester en de door de minister uitgezette beleidslijn uit haar brief uit 2010 2 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 meldingen 3 ; 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 www.rijksoverheid.nl/documenten-en-publicaties/persberichten/2010/02/16/ter-horst-wil-een-meldkamer-voor-alle-hulpdiensten.html 3 Zie het Programma van Eisen voor een nadere uitleg van de begrippen spoedeisend en niet-spoedeisend Blad: 8 / 24 Versiedatum: 15 nov. 2012
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. Blad: 9 / 24 Versiedatum: 15 nov. 2012
2 Rollen en gebruikers DCU 2.1 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 verzorgingsgebied 4 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. Blad: 10 / 24 Versiedatum: 15 nov. 2012
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 Blad: 11 / 24 Versiedatum: 15 nov. 2012
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 Admin FB Gebr. Monitor ( lezer ) Rechten toewijzen aan rollen X Functioneel beheerder toevoegen/ bewerken/ verwijderen X Gebruiker toevoegen/bewerken/verwijderen X X Viewer toevoegen/ bewerken/verwijderen X X Regio toevoegen / bewerken/verwijderen X Vaste post toevoegen/ bewerken/ verwijderen X X Verzorgingsgebied vaste post definiëren/bewerken X X Voertuigen aanmaken X X Voertuigen toewijzen aan een vaste post X X Vrijgeven ( unlock ) gebruiker account X X Wijzigen wachtwoord X X Aanmaken nieuwe melding X X X Afdrukken van een lopende melding X X X X Afdrukken van een melding uit het archief X X X X Bevelvoerende Blad: 12 / 24 Versiedatum: 15 nov. 2012
Monitor ( lezer ) Functionaliteit Admin FB Gebr. Afsluiten en archiveren melding X X X Archief met afgesloten meldingen inzien X X X X Archief met afgesloten meldingen bewerken X X X Filteren van meldingen X X X X X Lopende melding bewerken X X X X Lopende melding inzien X X X X X Lopende melding doorsturen X X X Delen van een lopende melding X X X Delen van een melding uit het archief X X X Melding in behandeling nemen X X X Meldingskarakteristiek toevoegen X X X Opnieuw in behandeling nemen melding X X X Prioriteit wijzigen X X X X Rapportages genereren X X X Sorteren van meldingen X X X X X Verversen van het scherm X X X X X Voertuig potentieel inzien X X X X Voertuig (custom voertuig) toevoegen X X X Voertuigen lenen van een andere vaste post X X X Voertuigen inzetten X X X Bevelvoerende Blad: 13 / 24 Versiedatum: 15 nov. 2012
3 Relatie met GMS/NMS functionaliteiten 3.1 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 GMS- DCU 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 worden 6. 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. Blad: 14 / 24 Versiedatum: 15 nov. 2012
4 Functionaliteit tijdens incidenten 4.1 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 Genereren en versturen van bericht (melding) 4.2.1 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. Blad: 15 / 24 Versiedatum: 15 nov. 2012
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. Blad: 16 / 24 Versiedatum: 15 nov. 2012
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 Ontvangen van het verstuurde bericht door de DCU voorziening 4.3.1 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 Inrichten vaste post 4.4.1 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 Blad: 17 / 24 Versiedatum: 15 nov. 2012
Monitor (lezer) 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 4.4.2 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: <regionaam>#<vaste postnaam>#<vaste postnummer> 4.5 Incidentmanagement binnen de DCU voorziening 4.5.1 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. Blad: 18 / 24 Versiedatum: 15 nov. 2012
4.5.4 Uitgangspunten B.4.1 en B.4.2 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 Uitgangspunten B.5.1 en B.5.2 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 Uitgangspunten B.6.1 en B.6.3 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. Blad: 19 / 24 Versiedatum: 15 nov. 2012
5 Functionaliteit: rapportages 5.1 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. Blad: 20 / 24 Versiedatum: 15 nov. 2012