MAmbuVis

Im Projekt MAmbuVis (Mannheim Ambulance Visualization) wird eine allgemeine Untersuchung der Rettungsdienstdaten aus den Jahren 2017 bis 2019 aus dem Rhein-Neckar-Kreis vorgenommen. Das Hauptaugenmerk liegt hierbei auf der Visualisierung der benötigten Fahrzeit zu den einzelnen Einsatzorten in Hinblick auf die gesetzlich festgelegte Hilfsfrist von 10-15 Minuten in Baden-Württemberg. Zusätzlich lassen sich verschiedenste Einsatzszenarien schnell und gezielt visuell analysieren. Die Daten hierfür wurden direkt in der Rettungsleitstelle Rhein-Neckar erhoben und freundlicherweise zur Verfügung gestellt. Es konnte unter Anderem festgestellt werden, dass insbesondere in ländlich geprägten Gebieten wie dem Odenwaldbereich mit vermehrten Verzögerungen im Notfall gerechnet werden muss.

Einführung / Konzept

Einführung

Dieses Projekt entstand im Rahmen der Vorlesung “Grundlagen der Datenvisualisierung” (GDV) an der Hochschule Mannheim und hatte die Vorgabe, eine oder mehreren Datenquellen aus einem urbanen Bereich zu untersuchen und das Ergebnis zu visualisieren. Die Entscheidung fiel hier thematisch auf Daten der Rettungsdienste Rhein-Neckar. Diese bieten einiges an Potential in Sachen Fragestellung und Auswertbarkeit.

Motivation / Konzept

Da die Gruppe rein aus Studierenden der medizinischen Informatik besteht und aufgrund der emotionalen Nähe zur Gesundheitsmetropole Rhein-Neckar stand der medizinische Bezug von Anfang an fest. Durch Bekanntschaften speziell in den Odenwälder Bereich war uns zu Ohren gekommen, dass die Rettungsdienste bei einem Notfall in dieser eher abgelegenen Region teilweise deutlich länger unterwegs sind, als es in den dichter besiedelten Bereichen rund um Mannheim und Heidelberg der Fall ist. Dies sollte zentraler Punkt unserer Fragestellung sein.

Für solche Regionen gelten die gleichen Reaktionszeiten bei einer Alarmierung wie für alle anderen Städte und Kreise mit gesetzlich festgelegten Zeiten pro Bundesland. Es darf und sollte selbstverständlich keinen markanten Unterschied machen, ob jemand direkt in der Stadt, weiter außerhalb oder sogar ländlich wohnt. Bei einem Notfall zählt jede Minute.

Thesen

• Gibt es Gebiete im Rhein-Neckar-Kreis, die deutlich längere Anfahrtszeiten der Rettungsdienste aufweisen als andere?
• Könnte man solche Bereiche durch zusätzliche Wachen entschärfen?

Im Laufe des Projektes wurde spürbar, dass zugunsten der Reaktionszeiten des Tools nicht alle geografischen Bereiche berücksichtigt werden konnten. Dadurch beschränkten wir uns auf den Stadtbereich Mannheim. Der unerwartet große Umfang der Daten ermöglichte es außerdem, ein sehr mächtiges und umfangreiches Auswertetool zu entwickeln, das die Auswertung unterschiedlichster Fragen ermöglichte, sodass eine Einschränkung auf wenige Hauptthesen nahezu unmöglich wurde.

Daten

Datenquelle

Über einen Bekannten in der Leitstelle Rhein-Neckar erhielten wir eine Email Adresse, an die wir eine offizielle Anfrage mit Beschreibung unserer Aufgabenstellung, sowie der Idee der Auswertung schickten. Die Antwort dauerte einige Tage, sodass wir uns schon nach anderen Konzepten umschauten. Die Reaktion auf unsere Mail war dann allerdings überraschend entgegen- und zuvorkommend. Uns wurde lediglich mitgeteilt, dass die Daten anonymisiert werden müssen, was uns sowieso bewusst war und wir wurden gefragt, für welchen Zeitraum die Daten benötigt wurden. Wir entschieden uns für die Jahre 2017 bis 2019. Da unsere Anfrage im Dezember 2019 gestellt wurde lagen die Daten für diesen Monat noch nicht vor. Die erhaltenen Datensätze hatten ein einfaches CSV-Format und waren auf 3 Dateien aufgeteilt - eine pro Jahr.

Die Daten umfassten unter Anderem den Zeitpunkt der Alarmierung, den Zeitpunkt des Eintreffens der Einsatzkräfte am Einsatzort, den Einsatzmitteltyp (die Art des ausgesandten Fahrzeugs), die Information, ob das Einsatzfahrzeug mit Sondersignal gefahren ist (Blaulichteinsatz), den Grund des Einsatzes (Sturz, Unfall, etc), sowie Orts- und Straßenname des Einsatzortes.

Datenauswertung

Die Auswertung der Daten gestaltete sich als eher schwierig, da sie deutlich mehr Informationen enthielten als erhofft und erwartet. Nach ein wenig herumprobieren in Tableau kamen wir schnell zu der Erkenntnis, dass sich uns eine gute Gelegenheit bietet, unsere Thesen zu erweitern bzw. zu verallgemeinern, um das Meiste aus den gegebenen Daten herauszuholen. So wurden verschiedene Filtermöglichkeiten erörtert, die sich möglichst umfangreich und sinnvoll kombinieren lassen. Zu den Filtermöglichkeiten gehören unter Anderem unterteilte Kategorien, die Jahre, Monate, Wochentage, sowie die Art der beteiligten Einsatzfahrzeuge und ob diese mit oder ohne Signal unterwegs waren. Um die ursprüngliche These dennoch nicht gänzlich außer Acht zu lassen wurde aus Alarmierungszeit und Ankunftszeit eine zusätzliche Spalte mit der Fahrzeit errechnet, die ebenfalls als Filtermöglichkeit einsetzt wird.

Geodaten

Aus den Orts- und Straßennamen wurden mit dem python Framework “geopy” und dessen Dienst “nominatim” die Längen- und Breitengrade ermittelt, um die Punkte im Projekt auf der Karte korrekt markieren zu können. Hier zeigte sich die Schwierigkeit, dass nominatim nur eine Anfrage pro Sekunde zulässt und außerdem nach einer scheinbar zufälligen Anzahl Anfragen einen Server Timeout produziert. Dadurch musste das Skript manuell nach jedem Abbruch an der entsprechenden Datenstelle wieder neu gestartet werden. Eine Alternative zu nominatim hätte es von Google gegeben, allerdings war hier die maximale kostenlose Anzahl von Datensätzen auf 1000 begrenzt. Ein kurzer Test zeigte, dass sich diese Sperre auch nicht austricksen lässt, da die IP des anfragenden Rechners von Google geloggt und gesperrt wird. Da wir allerdings etwas über 400.000 Datensätze abzugleichen hatten war dieser Dienst für uns nicht nützlich.

Für einige spezielle Ortsangaben wie die Quadrate in der Mannheimer Innenstadt oder die Leitstellen gab es keine standardisierten Bezeichnungen, wodurch die Längen- und Breitengrade hierfür zunächst nicht ermittelt werden konnten. Teilweise konnte dies automatisiert gelöst werden.

Datenaufbereitung

Mit der suchen und ersetzen Funktion konnte beispielsweise HD in Heidelberg geändert werden. Die Bezeichnungen der Quadrate mussten allerdings aufwändig und langwierig manuell korrigiert werden.

Bis auf die Bezeichnungen der Orte gab es auch Abweichungen bei den Einsatzarten. Hier gab es zum Beispiel für den selben Einsatztyp die Bezeichnungen “Brandeinsatz (mGef.)”, “Brandeinsatz m. Gefährdung” und “Brandeinsatz mit Gef.”. Solche Probleme waren allerdings leicht automatisiert zu korrigieren.

Um die Liste der Einsatzarten übersichtlicher und geordneter zu gestalten wurden per Skript zur Laufzeit noch festgelegte Gruppen erstellt, die auf der GUI wählbar sind.

Prototyp / Ergebnisse

Prozess

Für unsere Realisierung eines interaktiven Visualisierungsprototypen, galt es geeignete Tools auszuwählen. Für die erste Datenexploration eignete sich Tableau, da wir uns hierfür bereits in der Vorlesung umfangreiche Kenntnisse angeeignet hatten. Dadurch war es uns möglich zunächst ohne beträchtlichen Mehraufwand eine kurze Datenexploration durchzuführen.

So zeigte sich, was zu erwarten war, dass in den frühen Morgenstunden deutlich weniger Notrufe eingehen als zur Mittagszeit. Was wir allerdings so nicht erwartet hätten ist der sichtbare Einbruch gegen 14 Uhr, der nur von Montag bis Freitag zu sehen ist. Mit anderen Worten könnte man vermuten, dass sich hier ganz klar die Geschäftszeiten sowie insbesondere die Mittagspause abzeichnen.

Ein weiteres Experiment in Tableau war die Untersuchung, ob sich bestimmte Muster bei unterschiedlichen Einsatzstichwörtern abzeichnen. So ist nicht überraschenderweise klar zu erkennen, dass im Winter die Zahl der Einsätze bedingt durch eine Pneumonie (Lungenentzündung) einen starken Ausschlag nach oben verzeichnet, wohingegen die Einsätze für eine Anaphylaxie (Allergischer Schock) insbesondere in den Sommermonaten einen Peak haben. Dies lässt vermuten, dass insbesondere in den Sommermonaten Juni bis August die Zahl der Bienen und Wespenstiche stark zunimmt, was wiederum bekanntlich ein Risikofaktor für allergische Überreaktionen ist.

Für uns war schnell klar, dass wir, da die Daten, die wir erhalten haben so umfangreich und wertvoll sind, ein möglichst umfassendes Tool erstellen wollen welches viel Raum für die Darstellung der Daten lässt. Wir wollten bewusst die Möglichkeiten offenhalten, wie feingliedrig die jeweiligen Daten dargestellt werden sollen und uns und den Nutzer nicht von vornherein darauf einschränken, dass beispielsweise nur unterschiedliche Jahre aber nicht die einzelnen Tage angezeigt werden können. Wir wollten ein Tool, welches einerseits über eine geobasierte Map einen Überblick darüber bietet, wo genau sich die betreffenden Einsatzstichwörter, also Einsätze, befinden. Auf der anderen Seite wollten wir einen detaillierteren Einblick über den Verlauf eines speziellen Einsatzstichwortes geben. Darüber hinaus sollen dem Nutzer verschiedene Filtermöglichkeiten angezeigt werden, bei denen sich die Karten interaktiv zueinander und den gewählten Filtern anpassen.

Für die Realisierung unseres Projektes haben wir verschiedene Frameworks in Betracht gezogen. Wir wollten ein Framework was uns die nötige Flexibilität bietet und leicht zu erlernen ist. Daher fiel die Entscheidung auf das Webframework Dash von Plotly.

Vorstellung des Prototypen

Der Prototyp unterteilt sich in drei grundlegende Felder. Auf der linken Seite ist ein Bubble Map Chart zu sehen. Diese zeigt in ihren Farben die Zeit, die von Alarmierung bis Ankunft am Einsatzort benötigt wurde an. Je „dunkler“ die Farben (von Gelb nach Blau), umso mehr Zeit wurde benötigt. Ursprünglich war die Idee die Farbskala von Grün nach Rot, gemäß dem Ampelsystem verlaufen zu lassen. Allerdings entschieden wir uns dagegen, um einer fälschlichen Signalwirkung bzw. einer indirekten Bewertung (rot = schlecht) entgegenzuwirken. Die Farbskala ist direkt neben der Karte angeordnet um dem Nutzer zu jeder Zeit einen direkten Vergleich zwischen den Farben der Punkte auf der Karte sowie der Farbskala zu bieten. Dadurch erkennt der Nutzer direkt, welche Farbe welche Bedeutung bezüglich der Anfahrtszeit hat. Zusätzlich zeigt die Größe der Punkte die Anzahl der Einsätze an. Bewegt der Nutzer nun die Maus über einen dieser Punkte, so erhält er in einem kleinen Pop-Up detaillierte Informationen wie beispielsweise die genauen Minuten bis zur Ankunft oder auch den Namen des Standorts.

Eine weitere elementare Einheit stellt das Balkendiagramm in der oberen rechten Ecke dar. Da uns aufgrund der Aktualität der Daten noch die Daten aus dem Dezember des Jahres 2019 fehlen entschieden wir uns bewusst für die Darstellung dieser Daten als Balkendiagramm. Zuvor (wie auch in den Tableau Explorationen zu erkennen), war hier die Überlegung, ein Flächendiagramm zu verwenden, da dieses dem Nutzer schnell einen geeigneten Zeitlichen Verlauf über mehrere Jahre, Monate oder auch Tage hinweg anzeigen kann und auf einen Blick erkenntlich macht. Diese Idee wurde allerdings verworfen, da insbesondere für den Monat Dezember ein starker Trend nach unten über alle Jahre hinweg zu erkennen war. Dies ist dem zuvor geschilderten Problem der „unvollständigen“ Daten innerhalb des Jahres 2019 geschuldet. Durch das Balkendiagramm ist für den Nutzer direkt besser erkennbar, dass für bspw. den Monat Dezember nur Daten aus den Jahren 2017 und 2018 verfügbar sind.

Die dritte Einheit in unserem Prototypen stellt der Platz für die vielen verschiedenen Filter dar. Hier können insbesondere für Nutzer mit vertieften Kenntnissen aus dem Rettungsdienstbereich die unterschiedlichen Einsatzstichworte gewählt werden. Die Einsatzstichworte wurden dafür in passende Oberkategorien eingeteilt, um ein systematisches, schnelleres Finden der jeweiligen Stichwörter zu fördern und damit langes Scrollen durch eine Liste mit 172 Stichwörtern zu vermeiden und die Übersicht zu verbessern. Des Weiteren können entweder alle Jahre oder nur eines von 2017-2019 ausgewählt werden. Zusätzlich kann zu jeder Zeit ein bestimmter Monat ausgewählt werden. Hat man hier kein spezielles Jahr ausgewählt, so werden die jeweiligen Durchschnittswerte aus allen drei Jahren für diesen speziell ausgewählten Monat angezeigt. Weiter kann zusätzlich ein bestimmter Tag ausgewählt werden, ähnlich dem Prinzip des Monatsfilters.

Wählt man einen dieser zuvor genannten Filter aus, so aktualisiert sich sowohl die Geomap als auch das Balkendiagramm um den dargestellten Informationsfluss so unkompliziert und selbsterklärend wie möglich zu halten. Darüber hinaus kann zusätzlich noch nach bestimmten Einsatzfahrzeugtypen (Krankenwagen = KTW, Rettungswagen = RTW, Rettungshubschrauber = RTH und Notarzteinsatzfahrzeug = NEF) gefiltert werden sowie danach ob die Einsatzfahrten mit oder ohne Signal stattgefunden haben. Diese Filtermöglichkeiten wurden bewusst gewählt da sie deutliche Unterschiede in der Anfahrtszeit aufzeigen können.

Zusätzlich gibt es die Möglichkeit, die Farbskala an bestimmte Zeitbereiche anzupassen. Standardmäßig ist diese bereits zwischen 5 und 15 Minuten vorgewählt, um dem Rahmen der gesetzlichen Hilfsfrist gerecht zu werden. Alle Werte die nun kürzer als die voreingestellten 5 Minuten oder aber auch länger als die eingestellten 15 Minuten sind, werden weiterhin angezeigt (in der Farbe der Grenzbereiche, also Gelb oder Blau) und nicht ausgeschlossen. Um Verwirrungen diesbezüglich zu umgehen, da man als Nutzer leicht darauf schließen könnte, dass man mit der Veränderung der Skala die entsprechenden Werte darunter bzw. darüber ausblendet, haben wir uns dafür entschieden einen erklärenden Hinweistext zu diesem Filter anzuzeigen, der diesen Sachverhalt kurz und prägnant erklärt.

Da wir auch Nutzer, die kein Fachwissen aus dem Rettungsdienstbereich vorweisen können nicht ausschließen wollten und auch hier eine möglichst große und Effektive Wissensvermittlung angestrebt haben, entschieden wir uns dazu, einen zusätzlichen Button hinzuzufügen, der bereits vorgefertigte Filter enthält. Betätigt man diesen Button, so erscheint zunächst ein Popup mit den verschiedenen interessanten Ereignissen und einer kurzen Informellen Beschreibung. Wählt man nun solch einen Fall aus, so wird dem Nutzer eine detaillierte Beschreibung dessen gegeben, was zu sehen ist und interessant sein könnte, unterstützt mit kleinen Screenshots der hervorzuhebenden Stellen in der Karte und/oder dem Balkendiagramm. Wird nun dieser Fall tatsächlich vom Nutzer ausgewählt, so passen sich die entsprechenden Filter so an, dass das gewünschte Ergebnis angezeigt wird. Vorteil hierbei ist, dass der Nutzer keinerlei Vorwissen über die vielfältigen Filteroptionen mitbringen muss.

Der Nutzer hat zudem jederzeit die Möglichkeit, alle gesetzten Filter durch einen „Reset“ Button zurückzusetzen. Sollten einmal zu viele unterschiedliche gesetzte Filter den Datenbestand soweit einschränken, dass kein passender Inhalt und damit keine passende Visualisierung mehr angezeigt werden kann, so wird für den Nutzer ein entsprechender Warnhinweis ausgegeben.

Implementierung

Mittels Tableau haben wir zunächst eine umfassende Datenanalyse durchgeführt, um uns dadurch spezifische Gedanken und Ideen zu unserem Prototypen zu machen. Für die Visualisierung der Geodaten wurde das Webtool „Mapbox“ verwendet und in unsere Anwendung eingebunden. Mapbox bietet viele Möglichkeiten, Karten zu individualisieren. Hierdurch konnte das Layout der Karte einfach an unsere Bedürfnisse angepasst werden. Plotly unterstützt zum einen Mapbox Karten und zum Anderen Geo Karten. Da auf Geo Karten keine Straßen angezeigt werden und insgesamt das Layouten der Karte deutlich komplexer ist, als bei Mapbox haben wir uns für eine Mapbox Karte entschieden.

Entwickelt wurde der Prototyp in Python mit Dash, einem kostenlosen Open Source Framework von Plotly, welches es ermöglicht, schnell interaktive Webapplikationen für Visualisierungen zu erstellen. Ausschlaggebend für diese Entscheidung war unter Anderem, dass in unserer Projektgruppe bereits umfassende Python Kenntnisse gegeben waren und dieses Framework genügend Flexibilität in der Auswahl und Implementierung der Visualisierung bietet. Durch den modularen Aufbau von Dash ist es einfach, neue Diagramme, Filter oder Menüs in die Webapplikation einzufügen. Dies geschieht mittels HTML-Komponenten. Danach kann das Layout dieser Elemente einfach durch CSS angepasst und individualisiert werden. Außerdem gibt es Dash Bootstrap Komponenten, welche bereits zu einem gewissen Teil responsive und optisch ansprechender als die standard Dash Komponenten sind.

Die Dokumentation von Dash ist mittlerweile sehr ausführlich, allerdings befindet sich das Framework immernoch in der Entwicklung. Dies zeigt sich in der Performance beim Verarbeiten von großen Datenmengen. Um die Performance zu verbessern wurde Callback Cashing implementiert, welches Rückgabewerte von Callbacks speichert welche dann nicht erneut berechnet werden müssen. Außerdem wären einige Funktionalitäten wünschenswert, welche noch nicht existieren aber geplant sind, wie zum Beispiel mehrere Callbacks für gleiche Elemente oder komplette Individualisierung von Hover Elementen.

Die Verarbeitung der Daten geschieht mittels Pandas. Pandas ist eine Python Bibliothek, welche viele Funktionen zur Verwaltung und Bearbeitung von Daten bietet. Die Daten werden intern als sogenannte Dataframes repräsentiert, man kann sich diese wie Tabellen vorstellen. Durch die verschiedenen Methoden von Pandas können Dataframes einfach nach z.B. Stichwörtern, Einsatzwagen oder Zeit gefiltert werden oder aus den vorhandenen Daten neue Spalten erstellt werden. So wurde unter Anderem aus dem Zeitpunkt des Alarms und dem Zeitpunkt des Eintreffens am Einsatzort, die Dauer bis zur Ankunft berechnet. Dash akzeptiert Dataframes als Input und stellt die enthaltenen Daten dann dar.

Als Entwicklungsumgebung wurde Visual Studio Code verwendet, da dieses zum einen kostenlos ist und zum anderen durch unzählige Plugins beliebig für unterschiedliche Anwendungsfälle erweiterbar ist.

Erkenntnisse

Insbesondere im ländlichen Bereich (Odenwald) fällt eine starke Zunahme im Bereich der Anfahrtszeit auf.

Dies bestätigt unsere Vermutung und Theorie, dass ländliche Gebiete schlechter erreichbar sind. Die gesetzliche Hilfsfrist von 10-15 Minuten kann in diesen Bereichen oft nicht eingehalten werden (dunkelblaue Punkte auf der Karte).

Innerhalb Mannheims fällt auf, dass in bestimmten Stadtgebieten spezielle Einsatzstichwörter gehäuft vorkommen. Einsätze im Bereich der Alkoholvergiftungen finden vermehrt im Jungbusch und der Innenstadt an den Wochenenden statt.

Interessanterweise weist diese Graphik eine große Ähnlichkeit mit dem Einsatzstichwort „Schlägerei“ auf.

Bei dem allgemeinen Einsatzstichwort „Feuerwehreinsätze“ fällt besonders in den Quadraten Mannheims ein Ort auf, der weitaus mehr feuerwehrbedingte Einsätze vorzuweisen hat, als die restlichen Quadrate. Nach einer kurzen Recherche war klar, dass es sich bei dem im Quadrat J5 befindlichen Gebäude um das Zentralinstitut für Seelische Gesundheit handelt (Psychiatrie). Aufgrund von Arbeitserfahrungen eines Teammitgliedes in diesem Bereich und einer kurzen Recherche ist hier zu erwähnen, dass es sich bei diesen Einsätzen oftmals um Fehlalarme handelt.

Fazit

Mit MAmbuVis haben wir ein umfangreiches Tool erschaffen, welches eine schnelle und einfache Auswertung der Daten aus dem Rettungsdienst ermöglicht. Mit den detaillierten Filtermöglichkeiten können insbesondere Nutzer, die sich in diesem Bereich auskennen und gezielte Fragestellungen untersuchen möchten, aussagekräftige Grafiken erstellen. Aber auch für Nutzer, die im Bereich des Rettungsdienstes kein Vorwissen mit sich bringen, kann MAmbuVis eine erklärende Hilfestellung sein. Die vorgefertigten Filter enthalten gesonderte Ereignisse, die jeweils auch eine kurze Erklärung beinhalten und bei Betätigung alle nötigen Filter selbst einstellen.

Ausblick

Ausbaumöglichkeiten

Aus Performancegründen wäre es sinnvoll und hilfreich, die Daten in eine Datenbank einzupflegen. Bei diesem Schritt könnte man automatisiert Tabellen für verschiedene Daten anlegen, damit bei einem Filtervorgang im Projekt die Daten direkt ausgelesen werden können und nicht erst langwierig live gefiltert werden.

Desweiteren müsste man einige Daten standardisieren, um einheitliche Ergebnisse zu erhalten. Zum Beispiel sind die Standortdaten zum Zeitpunkt der Alarmierung nicht vereinheitlicht und somit nicht aussagekräftig auswertbar.

Die aktuelle Einteilung der Einsatzarten in Kategorien kann weiter überarbeitet und verfeinert, eventuell sogar noch um eine weitere Hierarchieebene erweitert werden, damit die Daten noch spezieller und feiner ausgewertet werden können.

Die in der aktuellen Version verfügbaren Filtermöglichkeiten könnten funktional erweitert werden. Beispielsweise wäre es möglich, Filter die keinen sinnvollen Effekt erzielen würden einfach auszublenden oder inaktiv zu schalten. Das Setzen eines Wochentags ohne Monatsfilter bringt aktuell zum Beispiel keinen wirklichen Mehrwert. Andererseits gibt es noch weitere Filtermöglichkeiten, die noch nicht implementiert sind. Ein Filter der nur bestimmte Jahreszeiten anzeigt wäre Sinnvoll für die Auswertung von saisonalen Einsatzarten wie Bienenstichen (Allergische Schocks) oder Stürze im Winter auf glattem Boden.

Die optische Gestaltung des Projekts bietet ebenfalls noch Erweiterungs- und Verbesserungspotential. So könnte man zum Beispiel die Farbskala der Anfahrtszeiten direkt in den Filterungsregler integrieren. Das würde die Lesbarkeit verbessern und die Bedienung intuitiver gestalten.

Möglichkeiten für Rettungsdienste und Leitstellen

Das Projekt bietet dem Anwender vielfältige Möglichkeiten der Auswertung von Einsatzdaten. Das Tool könnte dabei helfen, potentiell schwer erreichbare Bereiche zu identifizieren, was ja zunächst der Grundgedanke war. Eventuell könnte man aber auch bares Geld sparen, indem man die Einsatzwagen auf bestimmte Ereignisse angepasst ausstattet, die eher saisonal bedingt auftreten. So könnte in den Wintermonaten der Platz für Gegenmittel für anaphylaktische Schocks eingespart und für wichtigere Dinge genutzt werden. Einem Fachmann fallen hier sicher wesentlich mehr Nutzungsmöglichkeiten ein, dennoch sind wir als Team uns sicher, dass diese existieren.