Eisen aan een effectieve informatievoorziening voor de meldkamer brandweer

Eisen aan een effectieve informatievoorziening voor de meldkamer brandweer Versie 1.0 In opdracht van: Nederlandse Vereniging voor Brandweerzorg en Rampenbestrijding (NVBR) Brandweer Vraagorganisatie Informatiemanagement (BVIM) 30 maart 2011

NVBR/Zenc

Eisen aan een effectieve informatievoorziening voor de meldkamer brandweer Pagina 1 van 53

Het projectteam van Zenc voor deze opdracht bestond uit: ing. Jitze Bakker drs. Tom Kronenburg ir. Ton Monasso (projectleider) Josien de Reuver MSc drs. Barry Woudenberg De stuurgroep van de BVIM bestond uit: Jan Biemolt, programmamanager Intake en Noodhulp, namens de Raad van Korpschefs Mark Luijten (secretaris), secretaris Brandweer Vraagorganisatie Informatiemanagement NVBR Jaap van Meggelen, directeur gemeenschappelijke meldkamer Rotterdam-Rijnmond, voorzitter Netwerk Meldkamerdomein NVBR Mustapha Nazih, kwaliteitscontroller regionale brandweer Amsterdam-Amstelland, lid Netwerk Kwaliteitszorg Bart van Rosmalen, afdelingshoofd Paraatheid & Meldkamer Veiligheidsregio Utrecht, lid Netwerk Meldkamerdomein Anton Slofstra, regionaal commandant Zuid-Holland Zuid, lid Programmaraad Brandweerzorg Marijke van Veen (voorzitter), directeur Veiligheidsregio/regionaal commandant GelderlandZuid, portefeuillehouder Meldkamer in de Programmaraad Informatiemanagement Verder is in interviews en expertsessies dankbaar gebruik gemaakt van de expertise van: Sander Boon Arthur Haasbroek Watze Hepkema Ben Keizer Wout Knol

NVBR/Zenc

Rob Peters Sjoerd van der Schuit Gerke Spaling Joop Wessels Hendrik Jan de Wolf


Dag van een centralist in 2015 Op dinsdagochtend 8.00u gaat de telefoon in de meldkamer Noord-Nederland. De beller is op basis van zijn locatie direct met de juiste meldkamer verbonden. Bram, een van de intakers, ziet dat het om een mobiele beller gaat en krijgt de locatie direct op een kaart getoond. “112, waarmee kan ik u helpen?” De beller, die nogal overstuur is, doet verslag van een auto die met hoge snelheid van de weg is geraakt en tot stilstand is gekomen. De auto staat op circa tweehonderd meter afstand van de beller, dus er is nog niets bekend over aantal inzittenden of mogelijke andere kwetsbare verkeersdeelnemers. Bram zet de melding alvast door naar de backofficecentralisten van de politie (verkeersregulering en eventueel sporenonderzoek), de brandweer (redding) en de ambulancedienst (medische hulpverlening). Bram ziet op de kaart dat het om een provinciale weg met baanafscheiding gaat en vraagt de beller in welke richting het ongeluk plaatsvond. Bram vraagt de beller of hij beschikt over een telefoon met camerafunctie. Dat is het geval. De melder wordt gevraagd richting de botsing te lopen en daar een paar foto’s van de situatie te maken. Die kunnen worden ge-e-maild naar een voor het incident automatisch aangemaakt emailadres: [email protected]. Als de beller een nog modernere telefoon had gehad, was videobellen een mogelijkheid geweest. Wanneer de melder aankomt op de plaats van de botsing, blijkt dat de auto langzaam van de berm afrolt en dreigt de rivier in te glijden. Bram geeft deze informatie direct door aan de back-office brandweer, die een duikerspeloton informeert. De back-officecentralisten van brandweer, politie en ambulance hebben automatisch de nadere informatie over de locatie ontvangen en geven die door aan hun eenheden. Brandon, de centralist die verantwoordelijk is voor de back-office brandweer, besluit ook de ontvangen filmpjes door te sturen naar het hulpverleningsvoertuig en het duikerspeloton dat onderweg is. De filmpjes worden ter beschikking gesteld via de Mobiele Dataterminal in de voertuigen. Amber en Pol, collega’s van Bram, hebben van andere bellers meldingen over hetzelfde incident ontvangen. De incidenten worden samengevoegd na een melding van het meldkamersysteem dat de locatie en het type incident van verschillende meldingen overeenkwamen. Terwijl Bram zoveel mogelijk informatie van de melder ontving, was Brandon bezig met het bepalen van de juiste inzet van de brandweer. Het meldkamersysteem deed hem het voorstel om twee voertuigen vanuit twee kazernes te sturen, omdat de provinciale weg op dinsdagochtend vaak helemaal vaststaat en hulpverleningsvoertuigen ook vast zouden kunnen raken in het verkeer. De voorgestelde voertuigen zijn geselecteerd omdat zij de kortste verwachte aanrijtijd hebben. Hun precieze locatie is bekend via GPS-transponders, en de status die vanuit de voertuigen heel precies wordt bijgehouden, is dat de voertuigen op de kazerne zijn. Ook is rekening gehouden met de bezetting van de voertuigen. De opgeroepen voertuigen worden bemand door de beroepsbrandweer. Een derde kazerne die net zo ver van het incident verwijderd is als de tweede, is gepasseerd NVBR/Zenc


omdat daar met vrijwilligers wordt gewerkt die een hoge opkomsttijd hebben op dit tijdstip van de dag. (...) De bevelvoerder van de reddingsploeg meldt dat de inzittenden konden worden bevrijd. Het duikerspeloton hoefde niet te worden ingezet omdat de auto gestut kon worden. De brandweer meldt het incident af. De politie en ambulancedienst zijn nog wel bezig met het vervoer van de gewonden en het sporenonderzoek. In de meldkamer blijft het incident daarom openstaan. Terug op de kazerne kan de bevelvoerder zijn verslag optekenen in het brandweerinformatiesysteem. De basisgegevens, zoals de ingezette voertuigen, de belangrijkste tijdstippen en de classificatie van het incident zijn automatisch overgenomen uit het meldkamersysteem. Bram sluit een drukke ochtend af en draagt zijn dienst over. Wat een verschil met vijf jaar geleden, denkt hij. Toen wist nog niet eens het telefoonnummer van de beller, konden we niets met foto’s en moest ik elk nader bericht mondeling doorgeven. Over files wist ik niets. En de bevelvoerder belde achteraf waarbij ik zijn administratie mocht voorbereiden. Het is jammer dat de auto die van de weg af raakte een wat ouder model was dat nog geen automatische zelfmelding deed, anders had nog tijd gewonnen kunnen worden. Goed, tijd om naar huis te gaan. Ik rij wel even om - het zal vast nog druk zijn op de provinciale weg... Dit voorbeeld is bedoeld als inspiratie en geeft de denkrichting weer die in dit Programma van Eisen is gehanteerd. Niet alle functionaliteiten van systemen vallen binnen de afbakening van het Programma van Eisen, en ook hoeft het werkproces niet noodzakelijkerwijs zo te verlopen als is geschetst.

NVBR/Zenc


Voorwoord Beste lezer, Als elke seconde telt, is het verstandig soms wat langer de tijd te nemen. Door tijd en rust te pakken om goed na te denken over hoe de meldkamer brandweer, door een verbeterde informatievoorziening effectiever, sneller en uiteindelijk misschien goedkoper, kan werken. Ook voor de medewerkers betekent dit een verbetering. In de totstandkoming van dit Programma van Eisen hebben we die ruimte genomen. Om niet alleen na te denken over hoe we de knelpunten die in het hier en nu spelen kunnen aanpakken, maar ook hoe we de meldkamer, eenheden in het veld en de burger ook in de komende jaren goed kunnen bedienen. Dat gaat niet door alles bij het oude te laten. De informatievoorziening gaat op de schop, doordat brandweer, politie en ambulance samen een nieuw meldkamersysteem zullen selecteren. Daarnaast voert de brandweer verbeteringen in de huidige systemen door en realiseren we brandweerspecifieke functionaliteiten. Maar daarmee zijn we er nog niet. Als we echt effectiever willen zijn in de meldkamer, stelt dat ook eisen aan onszelf. Aan onze organisatie en processen, aan de ontwikkeling van informatiestandaarden en aan onze centralisten. Het verbeteren van de meldkamer is daarmee een avontuurlijke maar gecontroleerde reis. We weten waar we heen willen - de uitgangspunten en de kernprocessen zijn in dit document uitgewerkt - maar de weg ernaartoe zal af en toe moeilijk zijn. De eerste stappen in deze reis zijn al gemaakt. Bij het opstellen van dit Programma van Eisen is dankbaar gebruik gemaakt van de bijdrage van een groot aantal mensen binnen en buiten de brandweer. Dit document had niet opgesteld kunnen worden zonder de hulp van heel veel medewerkers binnen en buiten de brandweer. Ik hoop dat we die motivatie vasthouden voor het vervolg. Als over een aantal jaren de belangrijkste informatieknelpunten in de meldkamer zijn opgelost, nieuwe mogelijkheden zijn ontgonnen, we nog intensiever samenwerken met politie en ambulance en de meldkamer zowel de burger als het veld nog beter van dienst kan zijn, krijgen we hier vast voldoening en energie voor terug. Arnhem, 15 april 2011

Marijke van Veen Voorzitter Stuurgroep Programma van Eisen Directeur Veiligheidsregio Gelderland-Zuid / Regionaal Commandant

NVBR/Zenc


Managementsamenvatting De meldkamer is het brandpunt van de informatievoorziening van de brandweer. Voor burgers is het het eerste professionele contact bij een incident, en vrijwel alle hulpverleningsactiviteiten starten met een door de meldkamer gestructureerde alarmering. De eisen aan de meldkamer brandweer nemen toe. De samenwerking met veiligheidspartners als politie en ambulancedienst wordt intensiever. Bij crises wordt steeds meer informatie uitgewisseld tussen steeds meer partijen. Alarmeringen en inzetten worden flexibeler en nieuwe manieren van incidentmeldingen, bijvoorbeeld per smartphone, zullen hun intrede doen. De huidige informatiesystemen die de meldkamer ondersteunen kunnen niet aan die toekomstige verwachtingen voldoen. Doorontwikkeling of vervanging is nodig. Een groot deel daarvan zal in multiverband1 plaatsvinden. In het voorliggende Programma van Eisen geeft de Nederlandse brandweer aan welke eisen zij stelt aan de informatievoorziening in de meldkamer brandweer. Die eisen zijn niet gelieerd aan een specifiek systeem of een ontwikkel- of inkooptraject, maar geven aan wat de brandweer nodig heeft om haar werk goed te kunnen doen. De nadruk ligt om die reden op functionele eisen. Het Programma van Eisen is een combinatie van uitgangspunten over de functie en werkwijze van de meldkamer en de techniek, een beschrijving op hoofdlijnen van de werkprocessen van de meldkamer en een uitwerking in functionele eisen aan het systeem. Op een aantal punten zijn de eisen of werkprocessen wezenlijk anders dan wat op dit moment gebruikelijk is in de meldkamer: ● de intake is multidisciplinair; ● classificaties, protocollen en inzetvoorstellen worden in hoge mate gestandaardiseerd en geüniformeerd, maar de systemen blijven slechts beslissingsondersteunend; ● inzetvoorstellen worden dynamisch berekend, met gebruikmaking van actuele routeinformatie, incidentgegevens, posities van voertuigen en roosters; er wordt niet langer gebruikgemaakt van een statische kazernevolgordetabel; ● belangrijke gegevensuitwisselingen tussen verschillende systemen worden gestandaardiseerd; ● het aantal gegevensbronnen dat in de meldkamer toegankelijk is en vanuit de meldkamer beschikbaar kan worden gesteld aan anderen neemt toe. Het verbeteren van de effectiviteit van de informatievoorziening stelt niet alleen eisen aan systemen. Er zullen ook standaarden ontwikkeld, beheerd en vastgesteld moeten worden om gestandaardiseerde koppelvlakken mogelijk te maken. Daarnaast is de effectiviteit afhankelijk van een goede organisatie en van de professionaliteit van medewerkers.

1

In samenwerking met politie en ambulance.

NVBR/Zenc


Inhoudsopgave Dag van een centralist in 2015 ................................................................................................3 Voorwoord ...............................................................................................................................5 Managementsamenvatting ......................................................................................................6 Inhoudsopgave ........................................................................................................................7 1. Inleiding ...............................................................................................................................8 1.1 Vraagstelling ..................................................................................................................9 1.2 Inhoudelijke uitgangspunten PvE.................................................................................10 1.3 Doelstelling...................................................................................................................11 1.4 Werkwijze .....................................................................................................................11 1.5 Leeswijzer ....................................................................................................................12 2. Naar een effectieve meldkamer.........................................................................................13 2.1 Context .........................................................................................................................13 2.2 Criteria..........................................................................................................................13 2.3 Knelpunten ...................................................................................................................14 3. Uitgangspunten voor de werkwijze van de meldkamer .....................................................17 3.1 Introductie op de uitgangspunten.................................................................................17 3.2 Algemeen .....................................................................................................................18 3.3 Intake ...........................................................................................................................19 3.4 Uitgifte ..........................................................................................................................20 4. Processen ..........................................................................................................................21 4.1 Bedrijfsvoeringsmodel: de hoofdprocessen van de meldkamer...................................21 4.2 Resultaatgebieden .......................................................................................................22 4.3 Afnemen intake ............................................................................................................25 4.4 Verstrekken opdracht uitgifte .......................................................................................27 4.5 Monitoren uitruk en incident .........................................................................................30 5. Uitgangspunten voor de systemen ....................................................................................34 5.1 Context .........................................................................................................................34 5.2 Algemene uitgangspunten ...........................................................................................35 5.3 Specifieke uitgangspunten voor de meldkamer ...........................................................37 6. Eisen aan het systeem ......................................................................................................40 6.1 Algemene functionele eisen .........................................................................................40 6.2 Processpecifieke functionele eisen ..............................................................................41 7. Aanbevelingen ...................................................................................................................46 7.1 Standaardisatie van de informatie-uitwisseling ............................................................46 7.2 Doorontwikkeling van het PvE .....................................................................................48 7.3 Verbeteren en standaardiseren van de werkwijze .......................................................48 Bijlage I Benodigde functionaliteit andere systemen .............................................................50 Bijlage II Logboek activiteiten ................................................................................................52

NVBR/Zenc


1. Inleiding De maatschappij verwacht dat de brandweer snel en adequaat reageert op noodoproepen. De verwachtingen over wat snel en adequaat is, zijn de laatste jaren veranderd. Burgers zijn minder geneigd veiligheidsrisico’s te accepteren, en verlangen daarmee dat de brandweer gevaarlijke situaties nog beter bedwingt. Maar ook de techniek staat niet stil. De snelheid en precisie van informatie-uitwisseling wordt ook geprojecteerd op de brandweer. Vrijwel al het repressieve optreden van de brandweer start in de meldkamer. De meldkamer heeft ook veel ‘burgercontact’ door het aannemen van 112-meldingen. Daarmee heeft de meldkamer in het bijzonder te maken met de toegenomen maatschappelijke eisen. Recentelijk illustreerde de Onderzoeksraad voor de Veiligheid dit nogmaals in het rapport over de hulpverlening na het neerstorten van een toestel van Turkish Airlines.2 Een andere belangrijke ontwikkeling is de schaalvergroting van meldkamers. Enkele Veiligheidsregio’s hebben hun meldkamers al samengevoegd en een verdere clustering is voorzien in het regeerakkoord. De meldkamer brandweer ontbeert op dit moment de middelen om effectiever te zijn. Een belangrijk knelpunt is de informatievoorziening. De systemen die daarvoor worden gebruikt, hebben hun houdbaarheidsdatum overschreden. Op dit moment werkt de meldkamer brandweer met het Geïntegreerde Meldkamersysteem (GMS). Het GMS vormt een belangrijke informatiebron voor de primaire processen van de meldkamer (intake en uitgifte), maar ook voor andere activiteiten binnen de brandweerorganisatie zoals de vaststelling van vergoedingen voor vrijwilligers. GMS is niet meer voldoende voor de informatiebehoeften van de veiligheidspartners. Het systeem is bijvoorbeeld moeilijk te koppelen met andere applicaties, er zijn regionaal verschillende implementaties die onderling geen gegevens kunnen uitwisselen en het systeem ondersteunt geen moderne media. Op landelijk niveau worden voorbereidingen getroffen om de verschillende GMSimplementaties te vervangen door een nieuw systeem, dat grotendeels ‘van de plank’ zal worden gekocht: het Nationaal Meldkamersysteem (NMS).3 Die vernieuwing biedt mogelijkheden om de gesignaleerde knelpunten op te lossen. Een eenduidig beeld van de benodigde functionaliteit is nodig om de informatievoorziening van de meldkamer brandweer in de komende jaren te kunnen verbeteren en een zelfbewuste rol in de discussies over de vernieuwing van meldkamersystemen te kunnen spelen. Welke eisen stelt de brandweer aan de informatievoorziening in de meldkamer om burgers zo goed mogelijk te helpen, de risico’s voor brandweerlieden in het veld te beperken en de kosten aanvaardbaar te houden? 2

Onderzoeksraad voor de Veiligheid (2010), Hulpverlening na vliegtuigongeval Turkish Airlines Haarlemmermeer, p. 71-80. 3 Zie hiervoor ook: Raad MIV (2009), Business Case Nationaal Meldkamer Systeem - Gedeelde informatie bij incidentverwerking en HEC (2009), Audit onderzoek renovatie GMS. NVBR/Zenc


Vanuit deze gedachte is de Brandweer Vraagorganisatie Informatie Management (BVIM) van de NVBR het project “Verbeteren informatievoorziening meldkamer brandweer” gestart. De BVIM heeft onderzoeks- en adviesbureau Zenc gevraagd dit project uit te voeren. Het doel van het project is een Programma van Eisen (PvE) voor de informatievoorziening van de meldkamer brandweer te maken.

1.1 Vraagstelling De NVBR BVIM heeft Zenc in het kader van het project ‘Verbeteren informatievoorziening meldkamer brandweer’ het volgende gevraagd: “Lever een binnen de brandweer breed geaccepteerd programma van eisen op voor de verbetering van de functionaliteit van de informatievoorziening binnen de meldkamer brandweer, met een belangrijke plaats voor GIS-functionaliteit en inclusief de functionaliteit die de huidige GMS-koppelingen nu bieden.” De vraag bevat een aantal kernbegrippen, die we nader afbakenen: ● Meldkamer brandweer: de processen van de (gemeenschappelijke) meldkamer gericht op het afhandelen van incidenten waarbij de brandweer betrokken is. Wij beschrijven de ‘rode’ incidenten vanaf intake tot volledige afhandeling. De ‘rode’ afhandeling van incidenten in multiverband4 vormt een onderdeel van de beschrijving. De bijzondere verantwoordelijkheid van de brandweer in het alarmeren van de hoofdstructuur voor crisisbeheersing en rampenbestrijding valt ook binnen deze vraagstelling5. ● Informatievoorziening: het geheel van mensen, middelen en maatregelen, gericht op de informatiebehoefte van de organisatie. ○ Met mensen bedoelen wij de medewerkers van de brandweer die gericht zijn op het afstemmen van het aanbod (voorzieningen) op de vraag (informatiebehoefte van de organisatie). Hiertoe rekenen wij onder andere de informatiemanagers, de functioneel en technisch (applicatie)beheerders van de meldkamer. ○ Met middelen bedoelen wij zowel de voorzieningen als de informatie zelf. Voorzieningen kunnen zowel digitaal (bijvoorbeeld software) zijn als analoog (bijvoorbeeld papieren formulier) en zijn gericht op het opslaan, bewerken en verspreiden van informatie. Het betreft alle digitale en papieren informatie die nodig is voor het besturen en beheersen van de meldkamer brandweer. ○ De maatregelen zijn beleid, normen, standaarden en werkafspraken gericht op het vormgegeven, organiseren en gebruiken van de informatievoorziening.

4

In samenwerking met politie en ambulance. De Wet op de Veiligheidsregio’s draagt deze taak niet expliciet op aan een van de veiligheidsdisciplines. In de praktijk wordt dit uitgevoerd door de brandweer. We gaan ervan uit dat deze praktijk bestendigd wordt. 5

NVBR/Zenc


●

●

Programma van Eisen: dit PvE is niet gericht op een specifieke inkoop- of ontwikkelsituatie. Een verdere uitwerking van dit kernbegrip wordt in de inhoudelijke uitgangspunten van het PvE hieronder gegeven. Het PvE is ook onafhankelijk van de specifieke organisatorische context waarbinnen de meldkamertaken worden georganiseerd. De eisen zijn daarnaast zoveel mogelijk onafhankelijk van specifieke technologie geformuleerd. Functionaliteit: de mogelijkheden van een informatiesysteem om een proces in de meldkamer geautomatiseerd te ondersteunen. Wij focussen hierin op wat de informatievoorziening in de meldkamer brandweer moet kunnen (het ‘wat’) en niet op de manier waarop dit gebeurt (het ‘hoe’) (zie ook paragraaf 1.3). Het PvE gaat in op functionele eisen. Overige eisen aan het systeem, zoals niet-functionele eisen, zijn buiten beschouwing gelaten. Dergelijke eisen zijn alleen goed te definiëren als het wordt gebruikt in een specifiek traject. Daarvoor is bijvoorbeeld van belang of een bepaald systeem alleen door de brandweer wordt gebruikt of ook door haar veiligheidspartners, en welke partij het systeem beheert. Typische niet-functionele eisen gaan over bijvoorbeeld functioneel en technisch beheer, de gebruikersinterface, de aanwezigheid van trainingsmateriaal, release- en wijzigingsbeleid, back-up- en herstelmogelijkheden en de aansluiting op bestaande hardware, software, middleware en infrastructuren.

1.2 Inhoudelijke uitgangspunten PvE Dit PvE expliciteert de uitgangspunten en werkwijze van de meldkamer brandweer. We doen dat tegen een achtergrond waarin drie aspecten van belang zijn: (1) de aanstaande schaalvergroting, (2) de gewenste samenwerking tussen de (brandweer)meldkamers en (3) de nieuwe informatietechnieken die beschikbaar zijn. Op basis van deze achtergronden zijn de volgende inhoudelijke uitgangspunten van toepassing op de opdracht: ● Dit PvE is opgesteld voor de middellange termijn (komende 3-10 jaar). Het houdt hierin rekening met de situatie van de huidige meldkamers en met de aanstaande schaalvergroting. Het PvE is hiermee robuust. Vanwege de veranderende situatie zijn de processen en eisen niet specifiek uitgewerkt. Dat het PvE is gericht op een langere termijn betekent niet dat het in die tijd niet zal veranderen. Het PvE gaat uit van systeemkeuzes die toekomstbestendig zijn, maar er zal in de loop der jaren behoefte zijn aan nieuwe functionaliteit. Ook zullen nieuwe technische en informatiekundige mogelijkheden beschikbaar komen. ● Het PvE is opgesteld vanuit de wens te komen tot een sterke uniformering en standaardisatie van werkwijzen, informatievoorziening en systemen in de meldkamer brandweer. ● Het PvE geeft een beschrijving van het huidige meldkamersysteem en de mogelijke verbeteringen hierin. Deze verbeteringen zijn onafhankelijk van een specifiek systeem (GMS en/of NMS). Op basis van het PvE kan gekozen worden voor één nieuw systeem, maar ook een ‘systeem-van-systemen’ voor de toekomstige informatievoorziening in de meldkamer is een mogelijkheid. Het is bijvoorbeeld denkbaar dat het NMS, dat hoogstwaarschijnlijk in multiverband zal worden

NVBR/Zenc


●

●

geselecteerd en ingevoerd, niet alle voor de brandweer benodigde functionaliteten biedt. In bijlage I is een overzicht opgenomen van aanpalende systemen en functionaliteiten waarmee de meldkamerinformatiesystemen samenwerken. Het PvE heeft een multidisciplinaire kijk. De eisen voor de informatievoorziening zijn vanuit brandweerperspectief geformuleerd, maar belangrijke eisen die voor alle veiligheidspartners (brandweer, politie, ambulance) gelden, zijn in het programma meegenomen. Wij gebruiken de eerdere meldkamerprocesbeschrijvingen uit 2006 (KPMG) als vertrekpunt voor de nieuwe procesbeschrijvingen van de meldkamer brandweer.

1.3 Doelstelling De uitkomsten van dit project moeten bijdragen aan een beter verloop van de intake, uitgifte en monitoring in de meldkamer brandweer. Denk daarbij aan het sneller afhandelen van meldingen, het verminderen van onduidelijkheden over de locatie van incidenten en het beter kunnen afstemmen van de ingezette eenheden op het incident. Er zijn ook ‘interne’ verbeteringen beoogd, zoals het reduceren van onnodige administratieve handelingen en het mogelijk maken van schaalvergroting van meldkamers. Het gaat om verbeteringen binnen de meldkamer brandweer zelf, maar ook om het verbeteren van de samenwerking tussen meldkamers en die tussen de meldkamer en haar omgeving. We realiseren de doelstelling door een overtuigend toekomstbeeld van de meldkamer brandweer neer te zetten. Dit toekomstbeeld is opgesteld in samenspraak met de brandweersector. Het Programma van Eisen is toekomstbestendig en oplossingsneutraal; het gaat over het ‘wat’ en niet over het ‘hoe’ van de informatievoorziening in de meldkamer.

1.4 Werkwijze Het project om te komen tot dit PvE bestond uit twee fasen. In de eerste fase is een concept-PvE opgesteld op basis van expertsessies, interviews, documentanalyse en meldkamerbezoeken. In de tweede fase van het project is dit voorstel aangescherpt en getoetst in enkele gremia van de NVBR6. Het project is aangestuurd door een breed samengestelde stuurgroep.7 Bij de totstandkoming van het PvE is aangestuurd op een breed gedragen document. Voor de informatieverzameling en de validatie van de voorstellen is gestreefd naar een spreiding in niveaus (zoals centralist, hoofd meldkamer, informatiemanager en regionaal commandant) en regio’s van de betrokkenen. Het Programma van Eisen bestaat uit drie componenten. Allereerst is gestart met de strategische uitgangspunten: belangrijke keuzes over de functie van de meldkamer en haar positie ten opzichte van anderen. Vervolgens zijn de ‘resultaatgebieden’ intake, uitgifte en monitoring uitgewerkt, zodat zicht ontstaat op de relevante processen en vooral de berichten 6 7

Zie voor een overzicht van deze activiteiten bijlage II. Zie het schutblad voor de samenstelling van de stuurgroep.

NVBR/Zenc


die daartussen worden uitgewisseld. Hiervoor is gebruik gemaakt van de SqEMEmethodiek, die in hoofdstuk 4 nader wordt uitgelegd. Tot slot is een uitwerking in de vorm van eisen aan de informatievoorziening opgesteld. Naast enkele algemene eisen bevat deze processpecifieke eisen, die zijn afgeleid uit de beschrijvingen van de resultaatgebieden.

1.5 Leeswijzer Het PvE bestaat uit zeven hoofdstukken en een aantal bijlagen. Dit eerste hoofdstuk beschrijft de vraagstelling. Het volgende hoofdstuk geeft een verdieping van de vraagstelling door de ambitie (een effectieve informatievoorziening) te operationaliseren en het verschil met de huidige situatie in de vorm van knelpunten aan te geven. Hoofdstuk drie volgt hierop door de uitgangspunten voor de werkwijze van de meldkamer te benoemen. Die worden in hoofdstuk vier uitgewerkt in de vorm van processen. In hoofdstuk vijf zijn de uitgangspunten voor de informatie-architectuur en de techniek aangegeven. Hoofdstuk zes beschrijft de eisen aan de systemen die de informatievoorziening ondersteunen. Het is daarmee de meest concrete uitwerking en toepassing van de uitgangspunten rondom werkwijze en techniek. In hoofdstuk zeven sluiten we dit PvE af met een aantal aanbevelingen over ontwikkelactiviteiten die randvoorwaardelijk zijn voor het verbeteren van de informatievoorziening in de meldkamer. Bijlage I geeft aan met welke systemen het meldkamersysteem gegevens uitwisselt. Bijlage II bevat een overzicht van de projectactiviteiten waarbij deelnemers uit het brandweerveld betrokken waren.

NVBR/Zenc


2. Naar een effectieve meldkamer In dit hoofdstuk geven we aan wat we onder een effectieve informatievoorziening van de meldkamer bestaan. Vanwege de eis van toekomstbestendigheid van dit PvE starten we met het beschrijven van enkele belangrijke huidige en toekomstige ontwikkelingen die op de meldkamer afkomen. Daarna geven we aan welke set criteria we hanteren om effectiviteit mee te beoordelen, en tot slot benoemen we de belangrijkste knelpunten in de huidige informatievoorziening en -systemen. Dit hoofdstuk is gericht op strategische keuzes.

2.1 Context De belangrijkste ontwikkelingen die invloed hebben op de functie en werkwijze van de meldkamer zijn: ● Het aantal meldkamers in Nederland zal worden gereduceerd. Het precieze aantal is nog niet bekend, maar er moet rekening worden gehouden met een uitkomst tussen 3 en circa 10 meldkamerlocaties. De grenzen van eventuele ‘meldkamerregio’s’ vallen waarschijnlijk niet samen met die van Veiligheidsregio’s. ● De multidisciplinaire intake- en opschalingsprocessen worden als leidend gezien. Het principe van multidisciplinaire intake wordt door alle disciplines onderschreven en zal de komende jaren worden uitgerold. De samenwerking met politie en GHOR zal intensiveren. ● De maatschappij stelt hoge eisen aan het optreden van de hulpverleningsdiensten, terwijl zij tegelijkertijd ook eist dat de taken met minder middelen worden uitgevoerd. De bedrijfsvoering wordt verder verzakelijkt en geprofessionaliseerd. ● De ontwikkelingen rondom communicatietechnologie gaan snel. Zij zijn niet volledig te voorzien. Duidelijk is wel dat burgers (potentiële melders) over steeds ‘rijkere’ informatie beschikken die van waarde kan zijn bij de melding en afhandeling van incidenten. ● Binnen enkele jaren zal een nieuw landelijk meldkamersysteem beschikbaar zijn dat GMS vervangt. Dit meldkamersysteem zal minder regionale verschillen van werkwijzen toestaan dan nu het geval is met relatief autonome implementaties van GMS. ● Het gebruik van basisregistraties, inclusief het terugmelden van geconstateerde of vermoede fouten, wordt steeds vaker verplicht. De basisregistraties komen deels in de plaats van eigen databases.

2.2 Criteria Om een toetsingskader te hebben voor het beoordelen van de huidige situatie en de kwaliteit van het PvE, is het nodig te expliciteren wanneer we de informatievoorziening van de meldkamer succesvol vinden. We kiezen daarbij voor een set criteria die ook in de operatie herkenbaar is, omdat die meer houvast biedt dan een abstractere beschrijving van strategische criteria.

NVBR/Zenc


Onder een effectieve informatievoorziening van de meldkamer brandweer verstaan we een informatievoorziening die de meldkamer in staat stelt ● precies te alarmeren (precisie), door zoveel mogelijk goede informatie te verzamelen over de aard en de locatie van het incident en daarmee een goede classificatie van het incident te maken; ● snel te reageren op incidentmeldingen; de tijd tussen het moment dat een melder belt of anderszins zijn melding doorgeeft en dat alarmering plaatsvindt is zo kort mogelijk; daarvoor is nodig dat relevante informatie snel voorhanden is en zo min mogelijk bij de melder uitgevraagd wordt (verrijking incidentinformatie); ● melders van een adequate melderinstructie te voorzien; ● het repressieve optreden inclusief de hoofdstructuur van crisisbeheersing en rampenbestrijding adequaat te ondersteunen met extra informatie, snelle en precieze nadere alarmeringen (beschikbaarheid van informatie over actuele situatie en informatiedeling); ● de complexiteit van de afhandeling van meldingen weg te nemen bij de burger, door een multidisciplinaire dienstverlening te bieden; ● overweg te kunnen met in andere processen bepaalde beslisregels voor inzetvoorstellen (flexibele inzetvoorstellen); ● aanpalende processen te faciliteren door managementinformatie beschikbaar te stellen; ● de komende jaren een proces van schaalvergroting door te maken (schaalbaarheid); ● vrijwel geen uitval kent en altijd bereikbaar is (betrouwbaarheid); daarvoor is in ieder geval nodig dat meldkamers elkaars basistaken kunnen overnemen (onderlinge bijstand).

2.3 Knelpunten In de huidige informatievoorziening van de meldkamer brandweer bestaan knelpunten. De kwaliteit van de meldkamer brandweer heeft hierdoor in de afgelopen periode niet goed genoeg kunnen aansluiten bij de wensen en eisen die burgers en brandweerlieden stellen8. Vanuit deze knelpunten komen we in dit PvE tot verbeteringen voor de informatievoorziening in de meldkamer brandweer. We hebben de geconstateerde knelpunten in de huidige informatievoorziening gegroepeerd naar effect.

8

NVBR (2010), Standpunt van de Raad van Regionale Commandanten over de toekomst van de meldkamer brandweer. NVBR/Zenc


Impact op criterium

Knelpunt

Verrijking incidentinformatie

●

● ● ●

●

Precisie

●

●

Adequate melderinstructie Beschikbaarheid informatie over situatie

van actuele

De interactie tussen GMS en GIS-applicaties is onvoldoende en de geografische component in GMS voldoet niet (meer). Er kan onvoldoende worden gewerkt met beeldmateriaal en andere moderne media. Er is voor diverse zaken geen informatiekoppeling voor preparatieve informatie. Locatiebestanden zijn op dit moment onvoldoende gespecificeerd. Zo ontbreekt informatie over water op dit moment in het GMS. De meldkamer brandweer heeft onvoldoende toegang tot statistische informatie. De locatie van mobiele bellers wordt niet automatisch ontvangen, maar moet bij de beller zelf worden opgevraagd in het intakegesprek. De locatie van 112-meldingen kan niet getraceerd worden op (xy-)coördinaat.

Geen knelpunten. ●

Er is voor de brandweer geen goede informatiekoppeling om de status van voertuigen en mensen gemakkelijk bij te houden.

Informatiedeling

●

Het delen van informatie tijdens crises vereist veel handwerk. De informatie in GMS is niet altijd uit te wisselen met machinemachinekoppelingen.

Multidisciplinaire dienstverlening

●

GMS is per kolom georganiseerd. Het behouden van multidisciplinair overzicht is moeilijk.

Flexibele inzetvoorstellen

● ●

Er is geen inzet op (xy-)coördinaten mogelijk. Het inzetmechanisme werkt belemmerend. Het is verouderd en ondersteunt bepaalde nieuwe vormen van inzet van voertuigen niet of alleen met een hoge beheerslast. Het gebruik van Kazernevolgordetabellen (KVT’s) brengt een grote beheerslast met zich mee.

●

NVBR/Zenc


Managementinformatie

●

●

Schaalbaarheid

● ●

●

● ●

De informatievoorziening biedt op dit moment geen goede informatiekoppeling om lopende inzet- en managementinformatie uit GMS te kunnen halen. Centralisten besteden veel tijd aan administratieve handelingen die niet van direct belang zijn voor de repressie van het incident en vooral van waarde zijn voor processen buiten de meldkamer. Er is geen goede oefenmodus, waardoor niet goed getraind kan worden en operationele data vervuild raken door trainingsgegevens. De huidige opzet van GMS verschilt per regio. Werkzaamheden van de centralist verschillen per regio. Er wordt niet gewerkt volgens landelijk vastgestelde protocollen. Het beheer van de ‘content’ van GMS, met name de beslisregels, kan niet buiten het meldkamerdomein plaatsvinden. GMS is onvoldoende schaalbaar. Het kan geen grote hoeveelheden gelijktijdige gebruikers aan. GMS kent maatwerkkoppelingen die niet of nauwelijks gebruik maken van gestandaardiseerde berichtstandaarden of koppelvlakken. Daarmee zijn koppelingen moeilijk herbruikbaar.

Betrouwbaarheid

●

Het GMS kent op dit moment geen backupvoorzieningen bij uitval van het systeem.

Onderlinge bijstand

●

Regio-overstijgende bijstand wordt niet gefaciliteerd door het systeem. Zo is het niet mogelijk eenheden in andere regio’s te alarmeren of incidentinformatie te delen met andere meldkamers.

NVBR/Zenc


3. Uitgangspunten voor de werkwijze van de meldkamer In dit hoofdstuk beschrijven we de gemaakte strategische keuzes rondom de functie en werkwijze van de meldkamer. Het is de opmaat naar de beschrijving van de processen in het volgende hoofdstuk. Eerst lichten we de functie en totstandkoming van de uitgangspunten toe, waarna we de uitgangspunten zelf opsommen.

3.1 Introductie op de uitgangspunten In de meldkamer staat de afhandeling van incidenten met een spoedeisende hulpvraag centraal. De primaire taak van de meldkamer is het zo snel en effectief mogelijk alarmeren van de juiste eenheden, op basis van een melding van burger of (openbaar) meldsysteem. De meldkamer zet een vaak ongestructureerde melding om in een gestructureerde alarmering. Deze alarmering bevat de relevante informatie van de melder, eventueel verrijkt met informatie die de effectiviteit van de inzet verhoogt. De meldkamer is de schakel naar de operationele eenheden, als er nieuwe informatie over de melding beschikbaar komt. De meldkamer kan ook inzetverzoeken aan korpsen buiten het werkgebied richten. Daarnaast is zij beschikbaar om extra eenheden te alarmeren wanneer ‘het veld’ daarom vraagt. Tot slot is de meldkamer de plek van waaruit opschaling en afschaling wordt gestart, soms op basis van een eigen beslissing en soms op basis van een verzoek van buiten de meldkamer. Dit project gaat uit van het zojuist beschreven ‘primaire proces’. Eventuele taken die niet per se door de meldkamer hoeven te worden uitgevoerd, maar soms wel door centralisten of meldkamerorganisaties worden opgepakt, hoeven niet te worden ondersteund met een meldkamerinformatiesysteem. Een voorbeeld is het reageren op OMS-foutmeldingen. De uitgangspunten hebben alle betrekking op de informatievoorziening in de meldkamer. De gemaakte keuzes hebben geen zelfstandige status en bestrijken niet alle facetten van de meldkamer. Zo worden bijvoorbeeld geen uitspraken gedaan over de organisatiestructuur van de meldkamer, omdat die geen directe invloed heeft op de informatievoorziening. De uitgangspunten zijn soms ingegeven door eerder vastgestelde visies of externe ontwikkelingen9. Andere keuzes zijn specifiek voor dit project gemaakt. In dit hoofdstuk is gebruikgemaakt van de uitkomsten van de expertsessie strategische keuzes op 22 november 2010. De uitgangspunten voor de werkwijze van de meldkamer, en daarmee voor de invulling van de processen en de te stellen eisen aan de informatievoorziening, zijn gegroepeerd in drie paragrafen: algemeen, intake en uitgifte. 9

Zoals NVBR (2010), Standpunt van de Raad van Regionale Commandanten over de toekomst van de meldkamer brandweer. NVBR/Zenc


3.2 Algemeen ●

●

●

● ● ●

● ●

●

De werkprocessen en de inrichting van de informatievoorziening zijn zoveel mogelijk landelijk geüniformeerd. Voor zover verschillen tussen regio’s bestaan, kunnen deze wel betrekking hebben op de ‘beslisregels’, maar niet op de uit te voeren activiteiten en te hanteren classificaties. Onder activiteiten verstaan we handelingen die de centralist uitvoert. Beslisregels geven aan hoe en met gebruikmaking van welke informatie beslissingen worden genomen, door het systeem of de centralist. Classificaties zijn typologieën die worden gebruikt om een situatie te kunnen duiden met behulp van vooraf gedefinieerde klassen. Bijvoorbeeld: de Landelijke Meldingsclassificatie (die een type incident kan classificeren) moet overal gevolgd worden, maar regionaal kunnen wel verschillende inzetvoorstellen (beslisregels) bestaan. Het proces van intake en uitgifte (activiteiten) verschilt niet door deze variatie in beslisregels. De werkprocessen voor de centralist zijn geprotocolliseerd. Daarmee bedoelen we dat de handelingen van de centralist, de volgorde waarin die worden uitgevoerd en de informatie die wordt opgevraagd, geregistreerd en ter beschikking wordt gesteld in meer of mindere mate is voorgeschreven. De uitvoering van de processen mag niet teveel afhankelijk zijn van verschillen tussen centralisten. Aan de andere kant hebben centralisten wel de ruimte om af te wijken op basis van hun eigen, professionele oordeel. De informatiesystemen moeten de standaard-werkwijze volgens de protocollen makkelijk maken, maar mogen niet als keurslijf werken. Zo moet een centralist bijvoorbeeld kunnen afwijken van een inzetvoorstel als hij of zij dat nodig acht. De systemen moeten de gebruiker ondersteunen in het nemen van beslissingen. Daar hoort bij dat foutieve invoer of het negeren van belangrijke informatie wordt voorkomen. Het meldkamersysteem moet verschillende schaalgroottes van meldkamers aankunnen. Een Veiligheidsregio behoort tot slechts één meldkamer. Een meldkamer kan meerdere Veiligheidsregio’s bedienen. Niet alleen het meldkamersysteem, maar ook de systemen waarmee het gegevens uitwisselt zijn zoveel mogelijk uniform tussen de regio’s. Volledige uniformiteit is echter geen vereiste, en ook is het niet nodig dat meldkamers directe toegang tot alle systemen van andere meldkamerregio’s hebben. Meldkamers moeten kunnen beschikken over elkaars incidentinformatie, zowel voor het geval dat systemen uitvallen, als voor het kunnen leveren van bijstand. Meldkamers moeten eenheden die ‘geleend’ zijn van andere regio’s in het kader van het op peil houden van de restdekking zoveel mogelijk direct kunnen alarmeren, zonder tussenkomst van een centralist van een andere meldkamer. Managementinformatie wordt zoveel mogelijk afgeleid uit handelingen in het primaire proces. Centralisten voeren zo min mogelijk extra gegevens in die niet noodzakelijk zijn voor de uitoefening van de primaire functie van de meldkamer.

NVBR/Zenc


●

●

● ●

De meldkamer levert initiële informatie over incidenten aan andere organisaties, processen en systemen. De meldkamer is niet verantwoordelijk voor de verificatie of verrijking van informatie voor zover dit het meldkamerproces - inclusief de facilitering van het repressieve optreden - zelf niet dient. Een voorbeeld is het bepalen van het exacte adres voor de incidentrapportage wanneer de uitgifte op basis van xycoördinaten heeft plaatsgevonden. Terugmelding van foutieve gegevens uit basisregistraties vindt plaats door degene die gerede twijfel heeft over de juistheid van basisgegevens. Dat kan dus ook de meldkamer zijn. Het bewaken van de restdekking en het verplaatsen van eenheden worden tot de primaire taken van de meldkamer gerekend. Eventuele (tweerichtings)communicatie met burgers over incidenten behoort niet tot de taken van de meldkamer.

3.3 Intake ●

●

●

●

●

●

De intake vindt multidisciplinair plaats. De uitgifte wordt monodisciplinair afgehandeld. Het is mogelijk dat deze beide processen door dezelfde centralist worden uitgevoerd, maar er dient een procesmatig onderscheid te zijn. Daarmee wordt het mogelijk dat de functies worden gespreid over verschillende mensen of organisaties. Bellers naar 112 worden waar mogelijk direct verbonden met een multidisciplinaire intaker in het werkgebied van waaruit wordt gebeld. Tussenschakels (112, wie wilt u spreken?) worden zoveel mogelijk opgeheven. Dit geldt voor zowel oproepen van vaste als mobiele telefoons. De meldkamer kan gebruikmaken van ongestructureerde informatiebronnen zoals het reguliere world wide web, Twitter-feeds en YouTube-filmpjes. Er zijn echter geen koppelingen met de overige meldkamersystemen. Multimediale en nieuwe vormen van gestructureerde incidentmeldingen worden door het systeem ondersteund. Denk bijvoorbeeld aan het melden van een incident met een speciale applicatie voor smartphones, waarbij foto’s of filmpjes kunnen worden gemaakt, die samen met de locatie-informatie naar de meldkamer worden gestuurd. Incidenten die ‘onder beheer’ zijn bij een meldkamer moeten gedeeld kunnen worden met of overgedragen kunnen worden naar andere meldkamers en crisiscentra. Het is mogelijk om, indien nodig, meldkamers elkaars werkgebied te laten overnemen. Daarbij moet het ten minste mogelijk zijn om de intake en uitgifte van nieuwe meldingen te verzorgen. De meldkamer kan netcentrisch werken. Het kan informatie delen met andere partijen en daarover communiceren. De informatiesystemen mogen geen inhoudelijke beperking aan het delen van data opleggen. De meldkamer sluit aan bij de principes van bronhouderschap en deelt alleen oorspronkelijke informatie - elke partij is verantwoordelijk voor de ontsluiting van de gegevens die zij beheert.

NVBR/Zenc


3.4 Uitgifte ●

● ●

●

● ●

●

●

●

Het moet mogelijk zijn een uitgifte te doen voordat de intake volledig is doorlopen. Daarmee moet het mogelijk zijn om uit te geven zonder dat alle relevante informatie al beschikbaar is. De uitgifte zou binnen 1 minuut na de start van de intake moeten plaatsvinden. Het moet mogelijk zijn over te gaan tot decentrale uitgifte van meldingen met lagere prioriteit (Prio 3-meldingen), waarbij de meldkamer niet zelf de inzet van eenheden coördineert maar enkel meldingen doorgeeft. Er wordt gewerkt met dynamische inzetvoorstellen, waarbij per incident een of meerdere inzetvoorstellen worden gedaan die het best aansluiten op de actuele situatie. Daarbij wordt onder andere gebruik gemaakt van de positie van eenheden, de status van voertuigen en mensen en verwachte aanrijtijden. Meldkamers moeten incidentinformatie kunnen uitwisselen met eenheden uit andere regio’s, als deze worden ingezet voor de bestrijding van een incident. De meldkamer voert de waarschuwing en alarmering van de bevolking via het WASstelsel en eventuele andere kanalen (cell broadcasting, Twitter) uit. Zij is echter niet verantwoordelijk voor nadere berichtgeving of tweerichtingscommunicatie over reeds bij de meldkamer bekende incidenten met de bevolking10. Het moet mogelijk zijn om tot uitgifte over te gaan in andere regio’s dan die waartoe de meldkamer behoort. Het moet ook mogelijk zijn om landsgrensoverstijgend te alarmeren, mits daarvoor standaarden beschikbaar zijn. Voor uitgifte van eenheden die gestationeerd zijn buiten de eigen regio wordt een verzoek tot uitgifte gedaan aan de betreffende meldkamer. De activiteiten in het intake- en uitgifteproces moeten door verschillende gebruikers uitgevoerd kunnen worden. Deze gebruikers kunnen fysiek van elkaar gescheiden zijn en tot verschillende fysieke of organisatorische eenheden behoren. Voor de uitgifte is een meldkamer gekoppeld aan een geografisch gebied. De meldkamer voert in principe uitgiftetaken uit voor alle eenheden in dat gebied, ook als het (om de restdekking op peil te houden) geherloceerde eenheden uit andere meldkamerregio’s betreft. Een meldkamer heeft altijd overzicht over de status van alle eenheden in haar geografische gebied én alle eenheden die tot de aan de meldkamer toegewezen regio’s behoren. Een eenheid kan zowel (groepen van) voertuigen of individuen betreffen.

10

De discussie over de positionering van deze verantwoordelijkheid loopt nog. Voor dit PvE is ervan uitgegaan dat de taak niet tot het domein van de meldkamer behoort. NVBR/Zenc


4. Processen In dit hoofdstuk beschrijven we de hoofdprocessen van de meldkamer11. De processen zijn beschreven met behulp van de SqEME-methodiek12. We beschrijven de processen op twee verschillende niveaus: die van het bedrijfsmodel en die van de resultaatgebieden.

4.1 Bedrijfsvoeringsmodel: de hoofdprocessen van de meldkamer De SqEME-methodiek maakt gebruik van het ‘bedrijfsvoeringsmodel’ om op het hoogste abstractieniveau de hoofdprocessen van de meldkamer te benoemen. SqEME noemt de hoofdprocessen ‘resultaatgebieden’. De resultaatgebieden van de meldkamer zijn de hoofdwerkwoorden van de meldkamer. Deze resultaatgebieden zijn georganiseerd naar het soort proces. Wij onderscheiden de volgende soorten processen: ● Besturingsprocessen: strategische processen gericht op de besturing en inrichting van de meldkamer evenals het bepalen van de toekomst van de meldkamer; ● Ondersteunende processen: tactische processen gericht op het beheersen van de middelen van de meldkamer; ● Uitvoerende processen: processen die gericht zijn op de kerntaken van de meldkamer. Dit worden ook wel de ‘primaire processen’ genoemd; ● Verbeteringsprocessen: processen die gericht zijn op het monitoren en evalueren van prestaties in relatie tot de beleidsdoelstellingen danwel normen en het aanbrengen van verbeteringen in de processen. Met deze clustering van resultaatgebieden (hoofdwerkwoorden) van de meldkamer komen wij tot het volgende bedrijfsvoeringsmodel:

11

Voor het beschrijven van de referentieprocessen van de meldkamer maken wij mede gebruik van de volgende documenten: KPMG (2006), Brandweerprocesen in SOLL-situatie - Gemeenschappelijke Meldkamer Apeldoorn, Buijs, J. et al. (2007), Proces- en productbeschrijvingen Multidisciplinaire Intake en Multidisciplinaire Opschaling Meldkamer. 12 De SqEME-methodiek wordt door het informatiebeleidsplan “In Helder Perspectief” van de NVBR voorgeschreven als methodiek voor het beschrijven van de processen. Een uitgebreide beschrijving van de methodiek is te vinden in Van Oosten, R. et al. (2007), Procesmanagement en de Sqemebenadering, Kluwer. NVBR/Zenc


De hierboven gekozen werkwoorden (besturen, ondersteunen, uitvoeren, verbeteren) van de meldkamer zijn tot dusver niet gestandaardiseerd. Voor dezelfde processen gebruiken meldkamers soms verschillende benamingen. Bijvoorbeeld het doen van een uitgifte wordt ook wel aangeduid met ‘verwerken melding’, ‘dispatchen’, ‘alarmeren’ of ‘opdracht verstrekken’. Omwille van leesbaarheid en begrijpelijkheid, ook buiten het meldkamer brandweerdomein, is voor de huidige benamingen gekozen. Het kader met de stippellijn in het bedrijfsvoeringsmodel vormen de resultaatgebieden waarbinnen het dagelijks gebruik van de informatievoorziening tot uiting komt. Om deze reden werken wij deze vier resultaatgebieden ‘Afnemen intake’, ‘Verstrekken opdracht uitgifte’, ‘Monitoren uitruk en incident’ en ‘Bewaken dekking eenheden’ nader uit. Het resultaatgebied ‘Opstarten en afronden werkzaamheden’ is niet uitgewerkt, omdat hierin geen elementen in de informatievoorziening (berichten) tot uiting komen die nieuw of afwijkend zijn van de informatievoorziening van omkaderde resultaatgebieden. In hoofdstuk 5 is in de eisen wel rekening gehouden met dit resultaatgebied.

4.2 Resultaatgebieden Het concept resultaatgebied Het bedrijfsvoeringsmodel laat enkel op het hoogste abstractieniveau de resultaatgebieden (hoofdprocessen) zien. De uitwerking van deze resultaatgebieden vinden plaats in resultaatgebiedbeschrijvingen. Een resultaatgebiedbeschrijving is het tweede detailniveau NVBR/Zenc


waarmee SqEME processen weergeeft. De procesbeschrijvingen zijn te vinden op het derde detailniveau. Resultaatgebiedbeschrijvingen hebben een hoger abstractieniveau dan procesbeschrijvingen. Schematisch ziet dit er als volgt uit:

Een resultaatgebiedbeschrijving laat de samenhang zien tussen de processen binnen een resultaatgebied (hoofdproces). Een resultaatgebiedbeschrijving laat eveneens de samenhang zien tussen processen en informatie. Elk proces geven we in een resultaatgebiedbeschrijving weer als een blok met een werkwoord. Elk procesblok is verder uit te werken tot een procesbeschrijving met processtappen. De procesblokken worden hier niet uitgewerkt tot procesbeschrijvingen. Dit is om de volgende redenen: ● Resultaatgebiedbeschrijvingen bieden voldoende houvast om de informatievoorziening en processpecifieke functionele eisen te kunnen herleiden; ● Het nieuwe informatiesysteem dient toekomstbestendig en flexibel in de inrichting te zijn. De resultaatgebiedbeschrijvingen zijn gebruikt in plaats van procesbeschrijvingen om zo verschillen in bijvoorbeeld werkinstructies mogelijk te maken. Resultaatgebieden dwingen geen volgordelijkheid af, in tegenstelling tot procesbeschrijvingen. Zo kunnen meerdere processen gelijktijdig plaats vinden. Een

NVBR/Zenc


voorbeeld is de situatie waarin na de intake van een eerste melder alarmering plaatsvindt, terwijl tegelijkertijd intake wordt afgenomen van nieuwe melders van hetzelfde incident. In de resultaatgebiedbeschrijvingen zijn processen als blok weergegeven. De blokken zijn met elkaar verbonden door middel van pijlen. Elke pijl staat voor informatie, in SqEMEtermen een ‘bericht’. Een bericht kan verschillende verschijningsvormen hebben, zoals een protocol, formulier of een verzameling digitale gegevens. Het ‘meldkamerbeeld’ zoals dat gedefinieerd is vanuit het principe van netcentrisch werken is daarvan een voorbeeld. De pijlen vormen samen de informatievoorziening van de meldkamer. Zij geven het berichtenverkeer tussen processen weer. Om de verschillende elementen tekstueel te onderscheiden hanteren wij de volgende schrijfwijze voor de SqEME-elementen: SqEME-element

Schrijfwijze

Resultaatgebied

Dikgedrukt

Proces

Cursief

Bericht

Onderlijnd

Resultaatgebiedbeschrijvingen van de meldkamer De resultaatgebieden van de meldkamer zijn benoemd in het bedrijfsvoeringsmodel in de vorige paragraaf. In de hierop volgende paragrafen werken we resultaatgebieden van de uitvoerende processen nader uit. In de resultaatgebieden van de uitvoerende processen komt immers het gebruik van meldkamerinformatievoorziening het sterkst tot uiting. In de resultaatgebieden zijn we uitgegaan van de ‘standaardsituatie’13. Omwille van het PvE voor de nieuwe meldkamerinformatievoorziening zijn daarom specifiek drie resultaatgebieden nader beschreven. Dit zijn de belangrijkste hoofdwerkwoorden voor de uitvoerende processen van het bedrijfsvoeringsmodel: ‘Afnemen intake’, ‘Verstrekken opdracht uitgifte’, ‘Monitoren uitruk en incident’ en ‘Bewaken dekking eenheden’. Deze opdeling in resultaatgebieden komt voort uit de aard van de processen: ● Resultaatgebied Afnemen intake: Processen gericht op het verzamelen van incidentinformatie die nodig zijn om gewenste actie te kunnen bepalen. De mogelijke acties kunnen (reguliere) uitgifte, opschaling of doorverwijzing naar een andere meldkamer of organisatie zijn. Ook is het mogelijk dat er geen actie plaatsvindt in het geval van onjuiste, dubbele of valse meldingen.

13

De processen houden geen rekening met uitzonderlijke situatie zoals een grote storing op de meldkamer. NVBR/Zenc


● ● ●

Resultaatgebied Verstrekken opdracht uitgifte: Processen gericht op opdrachtverstrekking aan brandweereenheden. Resultaatgebied Monitoren uitruk en incident: Processen gericht op het bijhouden van de status en informatieverstrekking aan onder andere brandweer en bevolking. Resultaatgebied Bewaken dekking eenheden: Processen gericht op het bewaken van voldoende (rest)dekking in de regio.

4.3 Afnemen intake

Tot het resultaatgebied Afnemen intake behoren de processen die gericht zijn op het verzamelen van incidentinformatie die nodig is om gewenste zorg te kunnen bepalen. De mogelijke acties zijn uitgifte, opschaling of doorverwijzing naar een andere meldkamer of organisatie. Als er sprake is van een dubbele of valse melding vindt er geen actie plaats. Het resultaatgebied bestaat uit vier processen: ● Aannemen melding en uitvragen ● Instrueren melder ● Verrijken incidentinformatie ● Classificeren incident Het proces Aannemen melding en uitvragen wordt getriggerd door een Incidentmelding. Dit is een melding die zonder tussenkomst direct bij de multidisciplinaire (intake)centralist binnenkomt. Een Incidentmelding kan zijn: ● een geautomatiseerde melding: e-calls zoals OMS en voertuigalarmen;

NVBR/Zenc


●

een telefonische melding via 112 of andere telefoonnummers die op de meldkamer binnenkomen; ● een melding via C2000; ● een melding per e-mail, SMS of sociale media. De melding wordt aangenomen en de intake vindt plaats met behulp van een Uitvraagprotocol. Het Uitvraagprotocol voorziet erin dat de centralist ook ondersteund wordt in meldingen met een afwijkend procesverloop. Zo kan de centralist het Uitvraagprotocol verkort en/of in andere volgorde doorlopen bij nieuwe meldingen van een reeds bekend incident14. In het geval van gerichte meldingen aan de meldkamer op basis van digitale bronnen (bijvoorbeeld videobeelden doorgegeven door een ‘smartphone-applicatie’ of twitterberichten) worden deze ook gebruikt als Incidentmelding. De basisinformatie van een melding (locatie, aard, omvang, omstandigheden) wordt - voor zover bekend - geregistreerd in het informatiesysteem. Op basis van deze basisinformatie kan de meldkamer beslissen om de melding te classificeren en een vervroegde uitgifte te starten. Het proces leidt tot een in het informatiesysteem Geopende melding15. Na het aannemen van de melding en het uitvragen van de melding is het van belang dat de centralist instrueert wat de melder moet doen. Dit vindt plaats in het proces Instrueren melder op basis van een Instructieprotocol. De Geopende melding triggert dit proces. De centralist verstrekt aan de melder instructies (Instructie melder) om onder meer de veiligheid van de melder en omstanders te bevorderen. Vervolgens vindt het proces Verrijken incidentinformatie plaats. Dit proces is gericht op het verrijken van de informatie over het incident. De Geopende melding triggert dit proces. Bovendien is in dit proces informatie van belang over de directe en omliggende locatie en route (Route/locatieinformatie) evenals andere relevante statische en dynamische informatie (Overige bronnen)16. De Route/locatieinformatie en Overige bronnen zijn daarmee eveneens triggers voor dit proces op basis waarvan de centralist de incidentinformatie verrijkt. Daarnaast kijkt de centralist naar de relevante geschiedenis. De Incident- en locatiegeschienis geeft de centralist inzicht in de vraag of het incident reeds aangemeld of inmiddels opgelost is. De centralist kan tevens onderzoeken of er eerdere vergelijkbare incidenten op dezelfde locatie hebben plaatsgevonden. De Geschiedenis melder helpt de centralist om te beoordelen of de melder betrouwbaar is of een verleden heeft van valse meldingen. De meldkamer kan het incident nog niet classificeren als er uit dit proces Onvolledige incidentinformatie naar voren komt. Om deze reden zal de meldkamer de

14

Voor deze en andere meldkamerprotocollen geldt dat deze geen keurslijf moet zijn maar een hulpmiddel. 15 De samenhang in de informatievoorziening tussen de resultaatgebieden is weergegeven met een nummer. Een uitgaand bericht dat de centralist in een ander proces gebruikt is met een nummer weergegeven. De Geopende melding wordt bijvoorbeeld in het resultaatgebied Monitoren uitruk en incident gebruikt in het proces Begeleiden uitruk en incident. 16 Verdere verrijking van de informatie vindt in het resultaatgebied Monitoren uitruk en incident plaats. NVBR/Zenc


melder nader uitvragen. Het proces levert tenslotte Initiële incidentinformatie17 op dat de basis vormt voor het proces Classificeren incident en de vervolgprocessen in het resultaatgebied Verstrekken opdracht uitgifte. In het proces Classificeren incident bepaalt de meldkamer de classificatie van het incident. Het is mogelijk dat er sprake is van een Onterechte melding doordat het een dubbele of valse melding betreft. Het bericht Onterechte melding triggert het proces Afronden incident. Op het moment dat de melding terecht is, bepaalt de meldkamer op basis van de Landelijke meldingsclassificaties en karakteristieken welke classificatie danwel karakteristiek de melding krijgt. Dit leidt tot een Geclassificeerde melding die het proces Alarmeren triggert in het resultaatgebied Verstrekken opdracht uitgifte.

4.4 Verstrekken opdracht uitgifte

17

Er is gekozen voor de naamsgeving Initiële incidentinformatie om aan te geven dat de informatie nog niet getoetst is door eenheden ter plaatse. NVBR/Zenc


Tot het resultaatgebied Verstrekken opdracht uitgifte behoren de processen die gericht zijn op alarmering van (brandweer)functionarissen en -eenheden en het loggen van veranderingen in de prioriteit en inzetbehoefte. De brandweermeldkamercentralist is hierin ook verantwoordelijk voor het alarmeren van de hoofdstructuur van de rampenbestrijding en de crisisbeheersing. Het resultaatgebied bestaat uit drie processen: ● (Ont)Alarmeren ● Opschalen ● Afschalen Het proces (Ont)Alarmeren wordt getriggerd door een Geclassificeerde melding die voortkomt uit het resultaatgebied Afnemen intake. Daarnaast is het mogelijk dat een meldkamer van een naburige regio vanuit het proces (Ont)Alarmeren een Bijstandsverzoek doet18. Binnen het proces (Ont)Alarmeren wordt de melding danwel het Bijstandsverzoek omgezet in een Alarmeringsbericht dat wordt verstuurd naar uit te rukken brandweerfunctionarissen en -eenheden. Voor het bepalen van de gewenste inzet wordt de (Initiële) incidentinformatie gelegd naast vooraf bepaalde beslisregels omtrent het type en hoeveelheid eenheden (Beslisregels inzet)19. Voor het bepalen welke specifieke eenheden en functionarissen de centralist alarmeert wordt gebruik gemaakt van Route/locatieinformatie, Resource-informatie en informatie afkomstig uit Overige bronnen. Op deze wijze kan de centralist inspelen op factoren zoals weers-, locatie- en verkeersomstandigheden. Zo kan filevorming een reden zijn om andere of meer eenheden te alarmeren. Deze informatiebronnen kunnen zowel statische als dynamische informatie bieden zoals: ● de eigenschappen van de route en (omliggende) incidentlocatie; ● de locatie, status, prioriteit van resources (eenheden en functionarissen) in de buurt; ● de weersomstandigheden en andere relevante informatie ter bepaling van de alarmering van specifieke eenheden en functionarissen. Het systeem kan de meldkamer een suggestie doen voor de gewenste inzet. De centralist heeft de mogelijkheid hiervan af te wijken. Indien de meldkamer onvoldoende beschikbare eenheden heeft, kan de meldkamer een Bijstandsverzoek doen aan de meldkamers van naburige regio’s om eenheden te alarmeren. Vanuit het proces Afschalen kan dan het Verzoek tot ontalarmeren komen om (een deel van) de functionarissen/eenheden te ontalarmeren. Dit leidt tot een Ontalarmeringsbericht. Naast de reguliere alarmering kan bij incidenten van ernstigere aard opschaling plaats vinden. Het is belangrijk om op te merken dat de meldkamer in het proces Opschalen het Operationeel Team danwel BeleidsTeam (OT/BT) kan ondersteunen. De meldkamer

18

Meldkamers kunnen een Bijstandsverzoek doen aan andere meldkamers, in geval van incident in de buurt van de regiogrens en/of in geval van een lage dekking. 19 Initiële incidentinformatie is afkomstig uit het proces Verrijken incidentinformatie. Op het moment dat de incidentinformatie getoetst is door eenheden ter plaatse spreken we van Incidentinformatie. NVBR/Zenc


faciliteert daarmee ‘netcentrisch werken’20. Het proces Opschalen wordt getriggerd door een Prioriteitswijziging en Gewijzigde inzetbehoefte die kan voortkomen vanuit het proces Begeleiden uitruk en incident en/of door processen buiten de meldkamer brandweer. Bovendien kunnen melders van het incident, tijdens de processen in de resultaatgebieden Afnemen intake en Monitoren uitruk en incident, informatie verstrekken die het proces Opschalen triggert21. Een Prioriteitswijziging is een verzameling gegevens die een wijziging in de prioriteit van de incidentbestrijding tot gevolg heeft. Dit hoeft niet per se opschaling naar een GRIP te zijn, maar kan ook een extra uitgifte van functionarissen en eenheden betreffen zonder dat een GRIP wordt afgekondigd. Het proces Opschalen leidt tot een Verzoek tot alarmeren die vanuit het proces (Ont)Alarmeren tot een nieuw Alarmeringsbericht leidt. De meldkamercentralist registreert veranderingen in de prioriteit en inzetbehoefte door middel van het Logbericht opdracht opschalen. Dit is van belang voor de incidentverslaglegging. Nadat (opgeschaalde) bestrijding van het incident heeft plaatsgevonden of de ernst van het incident verminderd wordt er afgeschaald. De beslissing tot afschalen vindt buiten de meldkamer plaats. Het proces Afschalen wordt getriggerd door een Prioriteitswijziging en een Gewijzigde inzetbehoefte die voortkomen uit het proces Begeleiden uitruk en incident en/of door processen buiten de meldkamer. Daarnaast kunnen melders van het incident, tijdens de processen in de resultaatgebieden Afnemen intake en Monitoren uitruk en incident, informatie verstrekken die het proces Afschalen triggert22. Het afschalen kan in tussenstappen plaatsvinden. Het proces Afschalen leidt tot een Verzoek tot ontalarmeren, dat het proces (Ont)Alarmeren triggert. De meldkamercentralist registreert veranderingen in de prioriteit en inzetbehoefte door middel van het Logbericht opdracht afschalen. Dit is van belang voor de incidentverslaglegging.

20

Het actief delen van informatie binnen en buiten de brandweer met als doel een totaalbeeld van een incident te creëren. 21 Het is in deze situatie de centralist die de informatie interpreteert als een Prioriteitswijziging en Gewijzigde inzetbehoefte. 22 Idem. NVBR/Zenc


4.5 Monitoren uitruk en incident

Tot het resultaatgebied Monitoren uitruk en incident behoren de processen die gericht zijn op het bijhouden van de status en de informatieverstrekking aan onder andere brandweer, GHOR, politie en bevolking. In dit resultaatgebied komt de ‘lifelinefunctie’ van de meldkamer tot uiting. De processen in dit resultaatgebied zijn een logisch vervolg op de uitgifteprocessen (Ont)Alarmeren, Opschalen en Afschalen. Vanaf het moment van alarmeren begeleidt de meldkamer de uitruk door begeleiding tijdens het rijden naar het incident en tijdens het incident zelf. De meldkamer is dan een ‘spin in het web’ doordat zij informatie verzamelt en verstrekt, zowel op verzoek als proactief. Het resultaatgebied bestaat uit drie processen: ● Begeleiden uitruk en incident ● Waarschuwen en informeren bevolking ● Afronden incident Het proces Begeleiden uitruk en incident heeft tot doel de brandweerfunctionarissen tijdens de uitruk en ter plaatse te ondersteunen met informatie over het incident, het effectgebied en het verzorgingsgebied. Hiertoe behoort bijvoorbeeld ook het deelproces plotten van informatie over personen, rijdend materieel en te vervoeren materieel (haakarmbakken of losse gereedschappen). In deze stap verrijkt de centralist informatie over incident met koude (statische) en warme (dynamische) gegevens. Voorbeelden van koude gegevens zijn basisgegevens uit NVBR/Zenc


(basis)registraties zoals de Basisregistratie Adressen en Gebouwen (BAG), Basisregistratie Ondergrond (BRO) en Wet informatie-uitwisseling ondergrondse netwerken (WION). Ook informatie over vergunningen, inspecties en andere objectinformatie zijn vormen van koude informatie. Voorbeelden van warme gegevens zijn informatie van hulpdiensten ter plaatse, videobeelden, burgerbeelden via sociale media en dynamische real-time meetgevens zoals meteo. Het proces wordt getriggerd door een Informatieverzoek, Operationele informatie, Route/locatieinformatie, Overige bronnen en/of nieuwe Geopende Meldingen zijn de andere triggers. ● Operationele informatie zijn berichten ‘vanuit het veld’. ● Route- en locatieinformatie geven inzicht in de statische en dynamische informatie over de route en (eigenschappen van) de locatie (verzorgings- en effectgebied). Hiertoe behoort de koude en warme informatie over onder meer het aantal mensen ter plaatse, slachtoffers, gevaarlijke stoffen, weersinformatie, potentiële risico’s en xy-coördinaten van brandweereenheden. ● Overige bronnen kunnen bijvoorbeeld beelden van Youtube, Rijkswaterstaat, beveiligingssystemen of tekstuele berichten via Twitter zijn. Dit betreft informatie die via verschillende kanalen beschikbaar kunnen worden gesteld door burgers (melders) ter plaatse, overheden of beveiligings- en brandmeldsystemen. Melders van het incident die nadere informatie over het incident verstrekken, maken hiervan ook deel uit. Het proces Begeleiden uitruk en incident levert Incidentinformatie en Instructie op voor brandweereenheden ter plaatse. Bovendien kunnen de berichten Prioriteitswijziging en Gewijzigde inzetbehoefte uitgaande berichten (output) zijn van het proces. Deze berichten triggeren de processen in het resultaatgebied Verstrekken opdracht uitgifte. Tot slot zal dit proces het bericht Incident bestreden opleveren, wat leidt tot het proces Afronden incident. Tijdens de bestrijding van een incident kan in bijzondere gevallen een Verzoek tot alarmsignaal bij de meldkamer binnenkomen. Dit triggert het proces Waarschuwen en informeren bevolking. De uitkomsten van dit proces zijn een Alarmsignaal via een WASsysteem, zoals het activeren van de sirenes of het gebruik van cell broadcasting. De wijze van alarmeren wordt mede bepaald door het Communicatieprotocol. Het bericht Incident bestreden triggert het proces Afronden incident. Binnen dit proces wordt de externe communicatie beëindigd. Tevens rondt de meldkamer het incident administratief af, ook als het een Onterecht incident betreft. Afronding vindt plaats gebruik makend van het Afrondingsprotocol. Op basis van dit protocol vergewist de centralist zich ervan dat de registratie van het incident volledig is. Dit levert een Gearchiveerd incident op dat input biedt voor andere processen in het bedrijfsvoeringsmodel zoals Verbeterprocessen waarin evaluatie en verbetering plaats vindt. Het is tevens een trigger voor backofficeprocessen buiten de meldkamer zoals de berekening van de vergoedingen en de registratie van inzet ten behoeve van beroepskwalificaties.

NVBR/Zenc


4.6 Bewaken dekking eenheden

Tot het resultaatgebied Bewaken dekking eenheden behoren de processen die gericht zijn op het monitoren en bewaken van de dekking in de regio van de meldkamer. De processen in dit resultaatgebied worden getriggerd door alle wijzigingen in de beschikbaarheid en locatie van eenheden in de regio. Binnen dit resultaatgebied vindt de voortdurende afweging plaats of de actuele dekking voldoende is om op adequate wijze repressieve activiteiten uit te voeren. Indien de dekking onvoldoende is dient herlocatie van eenheden plaats te vinden. Het resultaatgebied bestaat uit twee processen: ● Monitoren dekking ● Herloceren eenheden Het proces Monitoren dekking heeft tot doel erop toe te zien dat de dekking in de regio voldoende is. Het Dekkingsprofiel bevat de normen voor de dekking waaraan de actuele dekking wordt getoetst. Het Dekkingsprofiel beantwoordt de vraag: hoeveel en welke type eenheden dienen minimaal waar in de regio beschikbaar te zijn? Het Dekkingsprofiel is niet statisch. De landelijke en regionale normen voor onder meer uitruktijden, regionale risico’s, maar ook bijzondere tijdelijke omstandigheden zoals evenementen, zijn van invloed op het Dekkingsprofiel. Wijzigingen in de beschikbaarheid en locatie van eenheden triggeren dit proces. Alle informatie over de locatie, status en prioriteit van resources (eenheden en functionarissen) is beschikbaar via de Resource-informatie. Het proces Monitoren dekking levert een beeld op van de dekking in de vorm van Resourceinformatie dat input biedt voor het proces (Ont)Alarmeren. Op het moment dat de actuele dekking niet voldoet aan het Dekkingsprofiel is er sprake van een (On)volledige dekking. Het NVBR/Zenc


bericht (On)volledige dekking bevat informatie over welke type eenheid op welke plek in de regio onvoldoende aanwezig is. Op het moment dat de dekking weer meer dan voldoende is, ontstaat er een bericht (On)volledige dekking, zodat eenheden naar hun gangbare locatie kunnen terugkeren. Het bericht (On)volledige dekking triggert in beide situaties het proces Herlocatie eenheden. Het proces Herloceren eenheden heeft als doel de herlocatie van eenheden om zo te blijven voldoen aan de minimale eisen gesteld in het Dekkingsprofiel. Het proces wordt getriggerd ofwel doordat sprake is van een (On)volledige dekking in de eigen regio of doordat een andere meldkamer een Extern herlocatieverzoek doet23. Om te bepalen welke eenheden (resources) geherloceerd kunnen worden maakt de centralist gebruik van de Resourceinformatie. De te herloceren eenheden kunnen afkomstig zijn zowel binnen als buiten de regio: ● Indien eenheden van de eigen regio geherloceerd worden binnen de regio (of naar een andere regio), doet de centralist een Intern herlocatieverzoek. ● Als eenheden van buiten de eigen regio nodig zijn om de eigen dekking op orde te houden, doet de centralist een Extern herlocatieverzoek. De herlocatie van eenheden heeft, net als de alarmering van eenheden tot gevolg dat de dekking verandert. Doordat eenheden verplaatsen en van status wijzigen wordt de Resource-informatie realtime bijgewerkt. Deze hernieuwde Resource-informatie voedt het proces Monitoren dekking.

23

Een Extern herlocatieverzoek is niet hetzelfde als een Bijstandsverzoek. Het wezenlijke verschil is de context waarin de andere meldkamer het verzoek pleegt. Dit is respectievelijk het ontstaan van onvoldoende dekking in de regio zonder een concreet incident en het verzoek om bijstand wegens een concreet incident (in het kader van het alarmeringsproces). NVBR/Zenc


5. Uitgangspunten voor de systemen In dit hoofdstuk beschrijven we de ‘technische’ uitgangspunten. De belangrijkste richtinggevende keuzes rondom informatie-architectuur en techniek zijn erin opgenomen. In paragraaf 5.1 schetsen we enkele technologische ontwikkelingen, om in paragraaf 5.2 de aansluiting bij breed aanvaarde uitgangspunten voor moderne informatie-architectuur te beschrijven. We sluiten in 5.3 af met specifieke uitgangspunten aan de meldkamersystemen.

5.1 Context In de komende jaren zullen veel technologieën beschikbaar komen die nu nog niet zijn te voorzien. De beschikbaarheid van filmpjes van branden, die door burgers met hun smartphone genomen kunnen worden, is bij de ontwikkeling van GMS destijds niet voorzien. Het blijkt nu, terwijl er nog steeds met hetzelfde systeem gewerkt wordt, bijna onmogelijk om die ontwikkeling ‘binnenboord’ te halen. Er zijn meer van dergelijke technologieën die bij de ontwikkeling van GMS niet konden worden gespecificeerd. Het voorspellen van de technologische ontwikkeling is erg moeilijk. Het is echter wel mogelijk om in de wijze waarop informatiesystemen zijn opgebouwd, rekening te houden met ‘aanpasbaarheid’. Daarbij gaat het erom dat systemen flexibel zijn om andere werkwijzes en andere technologieën te kunnen omarmen. Samenhangende brokjes functionaliteit zijn daarbij te beschouwen als ‘bouwstenen’ die makkelijk kunnen worden hergebruikt. Als er veel en wisselende bouwstenen zijn, kunnen bouwstenen onderling niet elke keer een nieuwe manier van communiceren overeenkomen. Dat zou het verkeer tussen bouwstenen volstrekt onoverzichtelijk maken, en elke dure ‘koppeling’ is maar eenmaal toepasbaar. Om de bouwstenen onderling te laten communiceren zijn daarom standaarden nodig. Die maskeren de complexiteit van de bouwstenen en bieden een ‘koppelvlak’ waar verschillende bouwstenen met elkaar kunnen communiceren. Een groot voordeel hiervan is dat de bouwstenen zelf kunnen wijzigen, maar dat dit geen gevolgen hoeft te hebben voor de wijze waarop de bouwstenen onderling communiceren. Dit maakt het bijvoorbeeld mogelijk om delen van het systeem te vervangen, zonder dat dit grote impact op de overige onderdelen van de informatievoorziening heeft. Deze uitgangspunten vormen de kern van het denken volgens het ‘service-oriented architecture’-concept (SOA). Voor de Nederlandse publieke sector is dat nader uitgewerkt in de NORA, die door de veiligheidssector wordt omarmd. Een van de gevolgen van het werken volgens een service-oriented architecture is dat het minder relevant wordt welke functionaliteiten in welke applicaties zijn vormgegeven. Het zal bijna altijd zo zijn dat een samenspel van applicaties, databases, koppelvlakken en communicatiemiddelen nodig is om het geheel van de gewenste functionaliteit te realiseren.

NVBR/Zenc


Een aantal van deze uitgangspunten komt ook terug in het brandweer-informatiebeleidsplan “In helder perspectief”24. Daarin wordt onder andere aandacht besteed aan het concept van basisregistraties en de noodzaak om gegevensmodellen en berichtspecificaties te beschrijven.

5.2 Algemene uitgangspunten Het PvE richt zich op wat de meldkamer brandweer van haar informatievoorziening eist. Het hoe wordt zo min mogelijk gespecificeerd. Toch worden wel enkele eisen gesteld aan de techniek zelf. Die moeten met name waarborgen dat de informatiesystemen die de meldkamer brandweer ondersteunen beheersbaar, flexibel en robuust zijn. Er wordt grotendeels aangesloten bij moderne principes voor applicatie- en informatie-architectuur. De specifieke uitwerking daarvan voor de wijze waarop de systemen in de meldkamer samenwerken wordt in de volgende paragraaf gegeven. De uitgangspunten zijn: ● Data, functionaliteit en bedrijfsregels zijn ontkoppeld. De data zijn toegankelijk buiten de applicatielaag van het informatiesysteem om. De bedrijfsregels moeten configureerbaar zijn. ● Voor de uitwisseling van gegevens tussen verschillende applicaties wordt zoveel mogelijk gebruik gemaakt van de principes van service-oriented architecture (SOA). De belangrijkste principes zijn weergegeven in kader 1. ● Voor de uitwisseling van gegevens worden niet-applicatiespecifieke berichtstandaarden gebruikt, die waar mogelijk zijn gebaseerd op gestandaardiseerde gegevensmodellen. ● De informatie is beveiligd. Dat wil zeggen dat de gegevens over een entiteit niet dubbel opgeslagen zijn, dat er een centraal autorisatiemechanisme is dat voorkomt dat ongewenste personen of systemen toegang tot het systeem krijgen en dat elk onderdeel van het systeem zelf verantwoordelijk is voor het afschermen van de gegevens voor anderen dan de door het centraal autorisatiemechanisme geautoriseerden. ● De informatievoorziening kent een hoge beschikbaarheid. Zowel geplande als ongeplande uitval dienen zo beperkt mogelijk te zijn. ● De meldkamer maakt zoveel mogelijk gebruik van basisregistraties en andere externe bronnen. Uit het oogpunt van de beschikbaarheid en actualiteit van gegevens wordt het bijhouden van data die elders al bekend zijn zoveel mogelijk vermeden. ● De software kan werken op en met middleware, hardware en randapparatuur die bij meerdere partijen en van meerdere producenten gekocht kan worden. ● Er wordt aangesloten bij de meest relevante fundamentele principes van de NORA, die zijn weergegeven in kader 2.

24

NVBR (2009), In Helder Perspectief.

NVBR/Zenc


●

Er wordt zoveel mogelijk gebruikgemaakt van berichtstandaarden, transportstandaarden en gestandaardiseerde gegevensmodellen. Voorbeelden hiervan zijn: ○ Geo-informatiemodel Openbare Orde & Veiligheid (IM-OOV) ○ Informatie-architectuur Sector Veiligheid (IASV) ○ OMS-norm (NEN 2535) ○ Architectuur Informatie Beleid Veiligheid (A-IBV)

Kader 1. Principes service-oriented architecture25. ● Een service is virtueel: de afnemer heeft geen weet van de implementatie van de dienst. De dienst is onafhankelijk van de afnemer. Scheiding van verantwoordelijkheid is expliciet vastgesteld. Voordeel hiervan is onafhankelijkheid van veranderingen van afnemer en leverancier. Voldoen aan het contract staat immers centraal; ● Een service is gestandaardiseerd: er is slechts één implementatie aanwezig van een verantwoordelijkheid. Voordeel is het rationaliseren van de standaard. Standaardiseren=massa, massa=kassa. De dienst wordt 'commodity' en eenvoudig te vervangen door een andere leverancier of goedkoper door een efficiëntieslag; ● Een service is modulair (vervangbaar) en compositioneerbaar. Standaard is niet flexibel. Flexibiliteit wordt bereikt door combineren (componeren) van standaards tot een nieuwe standaard; ● Een service is abstract: generiek, niet afgestemd voor 1 specifieke afnemer, maar op een doelgroep van afnemers; ● Losgekoppeld: afnemer en leverancier zijn maximaal onafhankelijk van implementatie van beide. Elke service is daarom autonoom. Er bestaat geen directe link of relatie tussen verschillende services. Services zijn zich ook niet van elkaar bewust.

25

Geciteerd uit: http://nl.wikipedia.org/wiki/Service_Oriented_Architecture.

NVBR/Zenc


Kader 2. Relevante fundamentele principes uit de NORA.26 ● Principe 5: Burgers, bedrijven en maatschappelijke instellingen beschikken over één identiteit die bruikbaar is voor alle contacten met organisaties in het publieke domein en die afhankelijk van de soort dienstverlening ook nodig is en gevraagd moet worden. Dit ongeacht de keuze voor een kanaal. Een en ander komt neer op één administratieve identiteit (één identificatienummer). Deze administratieve identiteit dient afgebeeld te worden op een (ook digitaal toepasbaar) identiteitsbewijs. ● Principe 8: Eénmaal uitvragen van gegevens, meermalen gebruiken; de organisaties in het publieke domein zullen burgers en bedrijven niet opnieuw om gegevens vragen die bij de overheid al bekend zijn. ● Principe 13: Organisaties in het publieke domein zorgen dat zij naar burgers, bedrijven en maatschappelijke instellingen periodiek verantwoording afleggen over de kwaliteit van de gerealiseerde dienstverlening. ● Principe 15: Organisaties in het publieke domein maken zichtbaar wat zij doen, welke besluiten zij nemen, welke gegevens zij hebben en gebruiken en wat hun werkwijze is. ● Principe 17: Organisaties in het publieke domein organiseren zich als een onderdeel van een integraal opererende en als eenheid optredende overheid, die in haar handelen naar burgers, bedrijven en maatschappelijke instellingen consistent en betrouwbaar is. ● Principe 18: Organisaties in het publieke domein gebruiken gegevens die accuraat, actueel en volgens wettelijke normen beveiligd zijn. ● Principe 19: Gebruik waar mogelijk generieke bouwstenen. Organisaties in het publieke domein streven er naar om beschikbare gemeenschappelijke voorzieningen te gebruiken, als deze op de punten functionaliteit, beveiliging en kosten gelijkwaardig zijn aan individuele voorzieningen. ● Principe 20: Standaardiseer en optimaliseer interne bedrijfsvoering.

5.3 Specifieke uitgangspunten voor de meldkamer De informatievoorziening van de meldkamer wordt ondersteund door verschillende systemen. Door de grote diversiteit aan functionaliteit, de samenwerking met politie en ambulance en overwegingen van beheersbaarheid is er geen reden om naar één integraal systeem te streven dat alle functionaliteit in zich draagt. Hoe dan ook moeten meldkamersystemen kunnen ‘praten’ met systemen buiten de meldkamer, bijvoorbeeld voor het delen van incidentinformatie bij crises of voor de interactie met basisregistraties als de BAG. 26

De NORA is een referentie-architectuur voor de Nederlandse overheid. Kenniscentrum e-overheid (2007), Nederlandse Overheid Referentie Architectuur 2.0, Den Haag: ICTU. NVBR/Zenc


Dit Programma van Eisen beperkt zich tot: ● de ondersteuning van de centralist bij de activiteiten in de resultaatgebieden “Afnemen intake”, “Verstrekken opdracht uitgifte” en “Monitoren uitruk en incident”; ● de beschrijving van de interacties met andere systemen, binnen en buiten de meldkamer. Er zijn een aantal ‘entiteiten’ die gebruikt worden in de uitwisseling met andere systemen. Voorbeelden zijn een “alarmeringsbericht”, een “incidentmelding” en een “incident”. Een entiteit is een conceptueel object, waarvan de eigenschappen tussen systemen doorgegeven worden. Een voorbeeld hiervan is een incidentmelding. Een incidentmelding kan telefonisch doorgegeven worden aan de centralist, maar ook via OMS, andere meldkamers of andere systemen binnenkomen. In dat geval moeten de systemen samenwerken. Met welke systemen de meldkamer precies gegevens uitwisselt, is niet gespecificeerd. Dat hoeft ook niet, omdat de uitwisselingen van gegevens over entiteiten via gestandaardiseerde koppelingen plaatsvindt. Mits er berichtstandaarden zijn gedefinieerd, hoeft het meldkamersysteem alleen de berichtstandaard te kennen. Als het systeem waarmee entiteitinformatie wordt uitgewisseld de berichtstandaard ook aanhoudt, praten de systemen in een uniforme taal met elkaar en hoeven ze elkaars bijzonderheden niet te kennen. We onderscheiden de volgende entiteiten: ● Incidentmeldingen ● Eenheden ● (Geo)objecten, ten minste: ○ Locaties ○ Gebouwen ○ Vervoersmiddelen ○ Leidingen ○ Weersverwachtingen ○ Actuele weerssituatie ○ Actuele verkeerssituaties ○ Routes ○ en andere Geo-objecten ● Alarm- en informatieberichten (waarbij ontalarmeringen een bijzondere vorm van alarmberichten zijn) ● Incidenten ● Melders (personen of systemen) Deze entiteiten kunnen zelfstandig of in wisselende combinaties gebruikt worden om functionaliteiten te ondersteunen. Voor het alarmeren en informeren zal gebruik gemaakt worden van alarm- en informatieberichten. Voor het berekenen van een snelste route kan gebruik gemaakt worden van locaties, eenheden (type inzet) en actuele verkeerssituatie waarna het systeem een route terugkrijgt. Wanneer het begeleiden van het incident

NVBR/Zenc


overgedragen of gedeeld wordt met andere systemen, zoals LCMS, kunnen alle entiteiten gebruikt worden. De relatie tussen entiteiten en processen is grafisch weergegeven. Niet alle entiteiten komen in alle processen voor.

Het is mogelijk dat een deel van de functionaliteiten die buiten dit PvE valt, samen met (een deel van) de functionaliteiten die er wel binnen vallen door dezelfde leverancier of als onderdeel van hetzelfde systeem worden gerealiseerd. Ook in dat geval blijft het vereiste van gestandaardiseerde koppelingen met berichtstandaarden rondom de entiteiten gelden. Wanneer de uitwisselingen rondom deze entiteiten, of ze nu binnen een systeem of vallen tussen verschillende systemen plaatsvinden, niet gestandaardiseerd zijn, beperkt dat de flexibiliteit van de informatievoorziening. Het is dan immers niet mogelijk om een deel van de functionaliteiten van het systeem te vervangen door een andere oplossing. In bijlage I zijn de functionaliteiten benoemd die buiten de scope van dit PvE vallen, maar waar de meldkamer wel gebruik van maakt. Deze functionaliteiten zijn gegroepeerd rondom de entiteiten. Een voorbeeld is het alarmeren van eenheden. Het geven van de opdracht tot alarmering aan een alarmeringssysteem en het bewaken van de voortgang zijn wel onderdeel van dit PvE, maar het systeem waarmee de alarmering wordt verspreid over eenheden is dat niet. Dat is immers niet alleen voor de meldkamer relevant, maar wordt door vrijwel alle brandweerlieden gebruikt en maakt gebruik van andere infrastructuren.

NVBR/Zenc


6. Eisen aan het systeem Dit hoofdstuk beschrijft de functionele eisen die aan de informatievoorziening in de meldkamer brandweer gesteld kunnen worden. De eisen in dit hoofdstuk vormen samen met de uitgangspunten en de resultaatgebiedbeschrijvingen het Programma van Eisen. Dit hoofdstuk kan niet zonder de overige onderdelen gelezen worden. De uitgangspunten en processen uit de eerdere hoofdstukken zijn zoveel mogelijk toekomstbestendig geformuleerd. Deze toekomstbestendigheid zoeken we ook in de functionele eisen die in dit hoofdstuk zijn neergelegd. Deze verzameling eisen is uitdrukkelijk geen bestek, maar een algemene richtlijn, die op een later moment geconcretiseerd en uitgebreid zal moeten worden om tot een concreet bestek te kunnen komen. Het PvE is immers gericht op de komende 3 tot 10 jaar. Werkprocessen, standaarden en normen zullen naar alle waarschijnlijkheid echter sneller veranderen. Om deze reden zijn ook de functionele eisen algemeen en abstract geformuleerd. We onderscheiden in dit overzicht algemene functionele eisen (verband houdend met ondersteunende en algemene processen), processpecifieke eisen (verband houdend met de processen en berichten zoals beschreven binnen de resultaatgebieden) en functionele eisen aan de uitwisselingen met andere systemen. Niet-functionele eisen zijn niet opgenomen, omdat die sterk afhankelijk kunnen zijn van een specifieke implementatie. Niet-functionele eisen zijn onder andere afhankelijk van de organisatie, het gekozen beheersmodel en de omvang van de vernieuwing van bestaande systemen. Elke functionele eis is geformuleerd als voorwaarde aan “het systeem”. Dit betekent niet dat er per se één systeem gebouwd zal worden. Het is goed mogelijk dat er een ‘systeem van systemen’ gebouwd wordt, waarin meerdere applicaties met elkaar samenwerken en alleen in combinatie met elkaar aan de opgestelde eisen voldoen. In enkele eisen wordt gerefereerd aan ‘eenheid’ of ‘eenheden’. Een eenheid kan in deze set eisen een individuele brandweerman zijn, een aantal brandweerfunctionarissen, een korps, een vervoersmiddel, een vervoersmiddel met bemanning en/of een combinatie van deze entiteiten.

6.1 Algemene functionele eisen ● ● ●

Het systeem kan alleen gebruikt worden door geautoriseerd personeel en geautoriseerde systemen. Het systeem bevat een autorisatiematrix waarin per rol is aangegeven welke functies de gebruiker kan uitvoeren en welke informatie deze kan opvragen. Gebruikers kunnen er bij het begeleiden van een complex incident voor kiezen om functionaliteit van het systeem die op dat moment niet relevant is, ‘uit te zetten’. De gebruiker moet zelf aangeven welke functionaliteiten hij/zij niet wil gebruiken.

NVBR/Zenc


●

● ● ● ● ●

Het systeem houdt loggegevens bij van alle gegevensuitwisselingen met andere systemen, van belangrijke gebruikershandelingen en van belangrijke aan de gebruiker gepresenteerde informatie. Het systeem kan managementinformatie verzamelen. Deze informatie wordt zoveel mogelijk afgeleid uit informatie die in primaire-procesactiviteiten wordt vastgelegd. De taken van het systeem kunnen met een minimale hoeveelheid handelingen en tijd worden overgenomen door een back-upsysteem. De beslisregels, de labels van de interface en de workflow zijn (in hoge mate) configureerbaar. De informatie-uitwisselingen met andere systemen zijn beveiligd op het niveau van data, transport en indien noodzakelijk infrastructuur. Waar mogelijk ondersteunt het systeem de processen door informatie op een (geografische) kaart te tonen.

6.2 Processpecifieke functionele eisen Afnemen intake Proces: Aannemen melding en uitvragen ●

●

● ●

Het systeem stelt de gebruiker in staat incidentgegevens in te voeren. Deze gegevens worden opgeslagen in het systeem. Het systeem geeft beschikbare informatie over melding/melder, mogelijk gerelateerde incidenten en oude incidenten op dezelfde locatie, automatisch weer. Het systeem doet een voorstel om meldingen (van alle disciplines) samen te voegen als het meerdere meldingen van hetzelfde incident lijken te betreffen. De gebruiker beslist hierover. Meerdere gebruikers kunnen aan hetzelfde incident werken en hierover via het systeem communiceren. Het systeem geeft de gebruiker de mogelijkheid om vanuit de melding direct een uitgifte te laten starten. Het moment vanaf wanneer dat kan is afhankelijk van het uitvraagprotocol.

Proces: Instrueren melder ●

●

Het systeem geeft de gebruiker (indien toepasselijk) aanwijzingen voor de melder, de zogenaamde melderinstructie. Dit proces is geprotocolleerd in het instructieprotocol. Ook van dit protocol kan de gebruiker afwijken. Het systeem geeft (indien reeds van toepassing) een prognose van de aankomsttijdstip van de gealarmeerde eenheden, zodat de meldinstructie daarop afgestemd kan worden.

NVBR/Zenc


Proces: Verrijken incidentinformatie ●

●

Het systeem dient de melding te verrijken met alle relevante informatie die beschikbaar is vanuit beschikbare andere meldkamersystemen of externe systemen. Het systeem verzamelt automatisch incidentinformatie uit overige bronnen (route/locatieinformatie, incidenten locatiegeschiedenis, geschiedenis melder) en toont de informatie aan de gebruiker. Het systeem biedt de gebruiker de mogelijkheid de melding handmatig aan te vullen met extra informatie afkomstig van de melder of andere bronnen, waaronder niet gestructureerde bronnen zoals sociale media.

Proces: Classificeren incident ●

●

Het systeem stelt op basis van de informatie rondom de incidentmelding automatisch een meldingsclassificatie voor, gebaseerd op de landelijke meldingsclassificaties. De gebruiker kan deze meldingsclassificatie wijzigen of overnemen. Het systeem sluit de melding af (proces: afronden incident) wanneer de melding als een onterechte (dubbele of valse) melding wordt geclassificeerd.

Verstrekken opdracht uitgifte Proces: Alarmeren ●

● ●

●

●

Het systeem geeft de gebruiker een voorstel over de eenheden die de melding moeten afhandelen (het inzetvoorstel). Er wordt gebruik gemaakt van dynamische inzetvoorstellen. Dit inzetvoorstel wordt berekend met gebruikmaking van statische (bijvoorbeeld de standaardinzet behorend bij de meldingsclassificatie) en dynamische informatie (bijvoorbeeld de status en locatie van eenheden en manschappen en route- en locatie-informatie). Het systeem stelt de gebruiker in staat het inzetvoorstel over te nemen of te wijzigen. Het systeem stelt de gebruiker in staat om de geselecteerde eenheden te alarmeren, te ontalarmeren en te informeren (gebruikmakend van de daarvoor ingerichte alarmering en informatiesystemen). Het alarmeringssysteem biedt beschikbare eenheden aan aan het meldkamersysteem en alarmeert de geselecteerde eenheden27. Het systeem stelt de gebruiker in staat om eenheden bij andere meldkamers 'op te vragen' vanwege assistentie of bijzondere inzet. Dit triggert een nieuwe melding bij de andere meldkamer. Het systeem kan een inzetvoorstel doen waarin alleen eenheden die niet in het eigen verzorgingsgebied staan voorkomen. Het incident moet in dat geval overgedragen worden aan de andere meldkamer.

27

Het alarmeringssysteem valt buiten de scope van dit PvE. Afhankelijk van het gebruikte alarmeringssysteem is het mogelijk om te alarmeren op basis van voorgedefinieerde groepen van personen, diensten en roosters, of op basis van dynamische status- en locatie-informatie van personen. NVBR/Zenc


Processen: Opschalen, Afschalen ●

● ●

Het systeem biedt de gebruiker de mogelijkheid de melding over te dragen aan een andere meldkamer, een (landelijk) incidentsysteem of aan een communicatie/commandopost ter plaatse28. Het systeem biedt de gebruiker de mogelijkheid om een prioriteitswijziging door te voeren. Het systeem doet na elke gewijzigde inzetbehoefte en prioriteitswijziging waarbij de prioriteit wordt veranderd een nieuw inzetvoorstel en/of ontalarmeringsvoorstel aan de gebruiker.

Monitoren uitruk en incident Proces: Begeleiden uitruk en incident ●

●

● ●

Het systeem stelt de gebruiker in staat om informatie over de omgeving, objecten en andere ter zake doende entiteiten op te vragen uit gekoppelde informatiebronnen en via gestructureerde gegevensuitwisseling te communiceren aan eenheden ter plaatse of andere eenheden. Het systeem stelt de gebruiker in staat om informatie over de omgeving, objecten en andere ter zake doende entiteiten toe te voegen of te verwijderen uit de opgevraagde informatie (bijvoorbeeld als de gebruiker weet dat een brug open staat of een weg niet bereikbaar is). De meldkamer is in staat om via spraakverbindingen te communiceren met eenheden. Het systeem is in staat om informatie te ontvangen uit incidentsystemen en vanuit mobiele dataterminals, deze op te slaan bij het incident en te tonen aan de gebruiker.

Proces: Waarschuwen en informeren bevolking ●

Het systeem biedt de gebruiker de mogelijkheid om de burgerbevolking te alarmeren via de systemen die daarvoor zijn ingericht.

Proces: Afronden incident ●

● ●

28

Het systeem adviseert de gebruiker wanneer het incident afgesloten kan worden, waarna de gebruiker de melding afsluit of deze nog open houdt. Het afsluiten van het incident gebeurt op basis van het afsluitprotocol. Het systeem slaat basisinformatie over het incident in haar eigen database op, voor gebruik bij latere incidenten. Het systeem draagt alle verzamelde informatie behorende bij het incident, inclusief logbestanden, over aan een datawarehouse.

Bijvoorbeeld een COPI, of een kazerne als er met decentrale uitgifte wordt gewerkt.

NVBR/Zenc


Bewaking dekking eenheden Proces: Monitoren dekking ●

●

Het systeem attendeert de gebruikers wanneer het dekkingsniveau onder in het dekkingsprofiel vastgestelde normen dreigt te zakken. Het systeem doet de betreffende gebruiker(s) een voorstel voor herlocatie van eenheden. Het systeem attendeert de gebruiker wanneer de restdekking van een dergelijk niveau is dat er niet langer gebruikt hoeft te worden gemaakt van ‘geleende’ eenheden.

Proces: Herloceren eenheden ●

●

Het systeem biedt de gebruiker de mogelijkheid een extern herlocatieverzoek aan een andere meldkamer te sturen. Die meldkamer verwerkt dit verzoek als een specifieke incidentmelding. Het systeem biedt de gebruiker de mogelijkheid een intern herlocatieverzoek uit te geven. Het systeem behandelt dit als een alarmering.

6.3 Functionele eisen aan de interactie met externe systemen ● ●

● ● ● ●

● ●

Het systeem kan ‘schakelen’ tussen verschillende externe systemen (bijvoorbeeld wanneer dit door uitval van verbindingen of andere systemen noodzakelijk is). De gebruiker kan via het systeem meldingen uit meerdere externe meldsystemen doorgeven, in ontvangst nemen en afhandelen. Voorbeelden van meldsystemen zijn OMS-meldingen, meldingen via smartphone-applicaties en zelfmeldende voertuigen. Het systeem kan realtime de status en locatie van alle eenheden in het verzorgingsgebied van de meldkamer tonen. Het systeem kan informatie over veelsoortige entiteiten uit andere systemen opvragen. Het systeem kan geo-gebaseerde informatie opvragen. De gebruiker kan met het systeem individuele eenheden en groepen van eenheden alarmeren en van informatie voorzien. De gebruiker kan via het systeem informatie over de melding, de incidentlocatie, het incident en de meldkameracties aan anderen (eenheden in het veld, andere meldkamers en andere systemen) overdragen. De gebruiker kan ook het incident overdragen aan een andere meldkamer. De status van de (verbindingen met) externe systemen is voor de centralist zichtbaar. Communicatie die door de centralist wordt geïnitieerd, maar wordt afgehandeld door een extern systeem, wordt altijd bewaakt. Een voorbeeld is het alarmeren van eenheden; het meldkamersysteem bewaakt of de systemen die verantwoordelijk zijn voor de eigenlijke alarmering een gereedmelding terugsturen.

NVBR/Zenc


● ●

Vanuit de meldkamer moeten fouten in basisregistraties kunnen worden teruggemeld aan de registratiehouders. Voor trainingen en systeemontwikkeling zijn er aparte systemen (instanties) beschikbaar, die geen interactie hebben met het operationele meldkamersysteem. Er is een instantie van het systeem beschikbaar voor gebruik bij uitval. Dit laatste systeem is wel gekoppeld aan het operationele systeem.

NVBR/Zenc


7. Aanbevelingen Met dit Programma van Eisen heeft de Nederlandse brandweer geëxpliciteerd welke voorzieningen zij in de meldkamer nodig heeft om effectief te kunnen zijn. Het PvE staat echter niet op zichzelf. Als morgen in alle meldkamers een prachtig stuk software zou zijn geïnstalleerd dat aan alle eisen uit dit document voldoet, heeft de brandweer een levensgroot probleem. De software kan hoogstwaarschijnlijk niet communiceren met andere systemen, omdat standaarden ontbreken of omdat andere systemen daar nog niet mee werken. De beslisregels kunnen niet worden geconfigureerd, omdat nog niet helder is hoe inzetvoorstellen tot stand moeten komen en op welke vlakken regio’s van elkaar mogen verschillen. Centralisten zijn niet getraind, en sommigen zullen veel moeite hebben om met de toename van het aantal informatiebronnen om te gaan. Het verbeteren van de informatievoorziening is dus meer dan het vervangen van hard- en software. Om de gewenste verbeteringen in het werk van de meldkamer te kunnen doorvoeren, zijn langs verschillende sporen inspanningen nodig, die we als aanbevelingen formuleren.

7.1 Standaardisatie van de informatie-uitwisseling ●

Stel berichtstandaarden en een gegevensmodel vast. Om gestandaardiseerde uitwisseling tussen verschillende informatiesystemen mogelijk te maken, moeten berichtstandaarden worden vastgesteld. Er kan gebruik worden gemaakt van bestaande internationale standaarden, maar veel standaarden zullen nog ontwikkeld moeten worden. De ontwikkeling van berichtstandaarden kan worden vereenvoudigd en versneld door eerst een gegevensmodel te ontwikkelen. Dat beschrijft welke betekenis aan bepaalde termen wordt gehecht (bijvoorbeeld: de meting van de aanrijtijd begint pas als de alarmering in gang is gezet), en hoe die formeel kunnen worden uitgedrukt (bijvoorbeeld: aanrijtijden drukken we uit in seconden, voertuigen hebben een zescijferig identificatienummer). Daar waar begrippen in multiverband worden gebruikt, is ook een multi-gegevensmodel aan te bevelen. De InformatieArchitectuur Sector Veiligheid (IASV) kan als een vertrekpunt worden gebruikt voor het brandweergegevensmodel. Daar waar door anderen ontwikkelde standaarden worden gebruikt, is het belangrijk te waarborgen dat de standaarden niet gerelateerd zijn aan een specifieke leverancier of oplossing. De specificaties van de standaard dienen voor zowel de brandweer als bestaande en nieuwe leveranciers toegankelijk te zijn en gebruikt te mogen worden in de aangeboden oplossingen. Waar mogelijk zou gebruik moeten worden gemaakt van bestaande internationale standaarden. Hoe minder specifiek Nederlandse eisen worden gesteld aan oplossingen, hoe groter het aantal leveranciers dat een mogelijke ict-oplossing kan aanbieden en hoe lager de kosten voor maatwerk.

NVBR/Zenc


●

●

●

Ontwikkel een informatie-architectuur voor de veiligheidssector. De informatiesystemen in de meldkamer vormen maar een klein deel van de informatietechnologie die de brandweer nodig heeft om haar processen te ondersteunen. Omdat systemen steeds meer gegevens uitwisselen en infrastructuren delen, bevelen wij aan om een aantal technische, organisatorische en informatiekundige uitgangspunten vast te stellen die voor alle applicaties en systemen gelden. Dat kan in de vorm van een informatie-architectuur. Daarin kan bijvoorbeeld worden vastgelegd welke informatiebeveiligingsprincipes worden gehanteerd, welke transportstandaarden voor elektronische berichten er worden gebruikt en wie verantwoordelijk is voor het functioneren van de verschillende applicaties. Het is sterk aan te bevelen de architectuur samen met de veiligheidspartners te ontwikkelen en te komen tot een set afspraken voor het OOVdomein. Er kan worden voortgebouwd op de Informatie-architectuur Sector Veiligheid (IASV), die in 2007 is opgesteld. De IASV is echter nog niet uitontwikkeld en omvat niet alle delen die een informatie-architectuur zou moeten omvatten. Ook is er nog niet genoeg aandacht geweest voor het beleggen van eigenaarschap, het beheer en het ontwikkelpad vanuit de huidige informatievoorziening. Streef naar een ‘ketenbestuur’ voor het OOV-domein. Het vaststellen van standaarden en informatie-architecturen, maar ook gezamenlijke werkprocessen zoals de multi-intake, kan de brandweer niet alleen. Om de ontwikkeling van standaarden te bevorderen, kan een ketenorgaan worden ingesteld dat ook de bevoegdheid heeft om de standaarden bindend vast te stellen. Dat orgaan moet dan bestaan uit gemandateerde vertegenwoordigers uit alle OOV-kolommen, op het niveau regionaal commandant of korpschef. Gebruik alleen gestandaardiseerde koppelingen na de introductie van een nieuw meldkamersysteem. Het gaat hierbij om de ‘transportstandaarden’, die aangeven hoe er technisch wordt gekoppeld. Bij de eventuele vernieuwing van informatiesystemen binnen en buiten de brandweer zal ten minste enige jaren een overgangssituatie bestaan waarbij systemen die wel en niet aan de eisen uit dit PvE voldoen naast elkaar bestaan en gegevens met elkaar uitwisselen. Daarbij moet erop worden gelet dat geen concessies worden gedaan aan het principe van gestandaardiseerde koppelvlakken. Stel dat er een nieuw meldkamersysteem zou worden ingevoerd dat grotendeels voldoet aan de eisen uit dit PvE, maar dat het koppelingen nodig heeft met bedrijfsprocessystemen of alarmeringssystemen die niet via web services gegevens kunnen uitwisselen. Dan is het niet verstandig om het meldkamersysteem zodanig aan te passen dat het zelf met de oude koppelingen overweg kan. In plaats daarvan zou aan de kant van de oude systemen een conversie moeten worden gemaakt, via bijvoorbeeld middleware. Voor het meldkamersysteem moet het principe van een applicatie-onafhankelijk communicatievlak overeind blijven. Anders raakt het meldkamersysteem weer verstrikt in complexiteit en daarmee moeilijke beheersbaarheid, die nu juist als knelpunt werd ervaren. Ook is de ervaring dat de overgang naar modernere koppelvlakken, met alle voordelen van dien, in zo’n geval vaak wordt uitgesteld.

NVBR/Zenc


7.2 Doorontwikkeling van het PvE ●

●

Benoem zowel een bestuurlijke als een ambtelijk verantwoordelijke voor het beheer van het Programma van Eisen. De waarde van het PvE is grotendeels afhankelijk van de mate waarin het aansluit op de beelden die er in de brandweersector bestaan over de gewenste manier van werken. Die beelden zijn in ontwikkeling, net als de technologische mogelijkheden en de maatschappelijke verwachtingen. Van tijd tot tijd behoeft het PvE daarom een update. De ervaring leert dat als niemand expliciet verantwoordelijk is voor het beheer van een PvE, het al snel in de bureaulade verdwijnt. Vanuit de Raad van Regionaal Commandanten zou bijvoorbeeld de PRIM de opdracht kunnen krijgen om het PvE periodiek te herzien. Voorkom dat het PvE uitdijdt, blijf scherpe keuzes maken. Een goed PvE is geen opsomming van alles wat door iemand gewenst wordt of wat technisch mogelijk is. Het is het resultaat van afwegingen over wat als belangrijk wordt gezien en wat niet, en wat wel en niet goed aansluit op de gewenste manier van werken. PvE’s worden na oplevering niet zelden verkeerd gebruikt. Zij worden dan gezien als een lijst van minimumeisen, waar vervolgens weer nieuwe wensen aan worden toegevoegd. Wij bevelen aan daar zeer terughoudend in te zijn, en nieuwe wensen op dezelfde manier te toetsen als in dit traject is gebeurd: passen zij in de uitgangspunten? Passen zij in de processen? Zijn zij consistent met overige eisen? Is het belangrijk? Valt het binnen de scope van de meldkamerinformatievoorziening? De kans is anders groot dat het PvE vervuild raakt en op enig moment geen realistische vertaling van de brandweerwensen meer is.

7.3 Verbeteren en standaardiseren van de werkwijze ●

●

Denk na over de centralist van de toekomst. Informatiesystemen worden gebruikt door mensen. Een andere manier van werken is niet mogelijk door alleen systemen aan te passen of te vervangen. Het vereist ook dat heel zorgvuldig naar de ‘eisen’ aan de organisatie en de gebruikers wordt gekeken. Wat hebben die nodig om op de nieuwe manier te kunnen werken? De betekenis van goede mensen mag niet worden onderschat. Een goede centralist kan zelfs met een slecht systeem nog veel voor elkaar krijgen. Omgekeerd heeft een slechte centralist niets aan een goed systeem; hij kan nog steeds de verkeerde beslissingen nemen, niet goed communiceren of te traag reageren. De competenties die van een centralist worden gevraagd zullen veeleisender zijn dan nu het geval is. Standaardiseer processen. Op dit moment bestaan er veel verschillen tussen regio’s in het verloop van meldkamerprocessen. Dat bemoeilijkt een overzichtelijke en kostenefficiënte informatievoorziening. Immers, verschillen zorgen voor extra complexiteit in de vorm van afwijkende handelingen. Ook maakt het samenwerking tussen regio’s lastig. Zelfs als het technisch mogelijk is dat regio’s toegang hebben tot elkaars informatiesystemen, zal er een noodzaak zijn om ook de betekenis van die informatie te standaardiseren. In de aanloop naar een landelijk

NVBR/Zenc


meldkamersysteem is het aan te bevelen om ook de meldkamerprocessen zoveel mogelijk landelijk te standaardiseren. Dat laat onverlet dat sommige regio’s een gerechtvaardigde behoefte aan maatwerk kunnen hebben. Elke keer zal dan bekeken moeten worden of het echt noodzakelijk is om van de standaard af te wijken, en zoja, hoe de consequenties voor samenwerking en kosten zo beperkt mogelijk kunnen worden gehouden.

NVBR/Zenc


Bijlage I Benodigde functionaliteit andere systemen De meldkamerinformatievoorziening, voor zover die binnen de afbakening van dit Programma van Eisen valt, is voor een goede werking afhankelijk van andere systemen en standaarden. Deze bijlage bevat een beknopte opsomming van functionaliteiten die in andere systemen, binnen of buiten de meldkamer en binnen of buiten de brandweer, beschikbaar moeten zijn om de beoogde werkwijze mogelijk te maken. We groeperen de systemen analoog aan de entiteiten die we in paragraaf 5.3 hebben gedefinieerd. De systemen bevinden zich in de ‘wolkjes’ van de daar opgenomen afbeelding. Gekoppelde systemen, gegroepeerd naar uitwisselingen over entiteiten ● Incidentmeldingen ○ Systemen voor het verwerken van telefoonverkeer, inclusief locatie- en afzendergegevens van de beller (bijvoorbeeld VOIP-telefooncentrales). ○ Systemen voor het ontvangen van geautomatiseerde meldingen (bijvoorbeeld OMS). ○ Systemen voor het faciliteren en ontvangen van gestructureerde meldingen op andere wijze (bijvoorbeeld een ‘112-app’ voor smartphones). ○ Systeem voor het ontvangen van meldingen via andere media (bijvoorbeeld video en location-based messaging). ● Eenheden ○ Systemen voor het doorgeven van de real-timelocaties van voertuigen en andere belangrijke hulpmiddelen. ○ Systemen voor het beheren van de beschikbaarheid van personeel. ○ Systemen voor het doorgeven van de statussen van voertuigen. ○ Systemen voor het doorgeven van de statussen van personeel. ○ Systemen voor de berekening van vergoedingen voor ingezet personeel. ● (Geo-)objecten ○ Aansluitingen op relevante basisregistraties (bijvoorbeeld de BAG, de BGT en de GBA). ○ Systemen voor het bijhouden van brandweerspecifieke informatie over objecten zoals gebouwen, verkeer, wegen en straten, leidingen en netwerken (gas/water/elektriciteit, data/internet, riool), meteorologische omstandigheden, routes en reistijden, personen, bedrijven, kadastrale gegevens, gegevens over voertuigen, boten, vliegtuigen. ○ Systemen voor terugkoppeling van onjuiste basisregistratiegegevens.

NVBR/Zenc


●

Alarmerings- en informatieberichten en incidentinformatie ○ Systemen voor het alarmeren van de juiste personen, op basis van beschikbaarheidsinformatie (bijvoorbeeld P2000 en Communicator). ○ Systemen voor het delen van belangrijke incidenten situatie-informatie met andere disciplines (bijvoorbeeld LCMS). ○ Systemen voor het delen van incidentinformatie met ingezette eenheden (bijvoorbeeld MDT en eventueel DBK). ○ Systemen voor het genereren van managementrapportages. ○ Systemen voor het opstellen van incidentrapportages. ○ Systemen voor ongestructureerde communicatie (tekst, spraak, video) met eenheden en functionarissen (bijvoorbeeld C2000).

NVBR/Zenc


Bijlage II Logboek activiteiten Activiteit

Datum

Interviews en meldkamerbezoeken Interview Jaap van Meggelen, directeur gemeenschappelijke meldkamer Rotterdam-Rijnmond

20 januari 2011

Interview Rob Peters, informatiemanager Veiligheidsregio Kennemerland

20 december 2010

Interview Bart van Rosmalen, afdelingshoofd Paraatheid & Meldkamer Veiligheidsregio Utrecht

28 december 2010

Interview Sjoerd van der Schuit, regionaal commandant Limburg-Noord

5 januari 2011

Interview Hendrik Jan de Wolf, functioneel specialist GMS

26 januari 2011

Meldkamerbezoek Veiligheidsregio Hollands Midden, gecombineerd met interview Arthur Haasbroek (beleidsmedewerker)

1 november 2010

Meldkamerbezoek Hulpverleningsdienst Regio Twente, gecombineerd met interviews met Gerke Spaling (informatiemanager) en Joop Wessels (coördinator meldkamer)

4 januari 2011

Bijgewoonde bijeenkomsten Programmaraad Informatiemanagement (PRIM)

7 oktober 2010, 20 januari 2011 en 10 maart 2011

Themasessie RRC

8 oktober 2010

NVBR/Zenc


Sessies Expertsessie strategische doelen

22 november 2010

SWOT-analyse in Netwerk Meldkamerdomein

28 september 2010

Validatiesessie processen en eisen 16 februari 2011 (experts: Arthur Haasbroek, Watze Hepkema, Jaap van Meggelen, Joop Wessels, Hendrik Jan de Wolf)

NVBR/Zenc


Eisen aan een effectieve informatievoorziening voor de meldkamer brandweer

Recommend Documents