Ziele überprüfen & Workflows schaffen

Bewertet man den aktuellen Stand des Servers, muss man sich zwangsläufig fragen, was bereits erreicht wurde, was sich damit konkret umsetzen lässt und welche Ziele überhaupt mit dem System verfolgt werden.

Aktuell existiert vor allem eine lose Sammlung verschiedener Tools. Diese sind ohne Frage hilfreich, jedoch fehlt ein durchdachter, durchgängiger Arbeitsablauf. Genau dafür müssen die Ziele deutlich konkreter formuliert werden als nur „ich möchte einen ELW-Server betreiben“.
Um diese Ziele sauber auszuarbeiten, hilft es, sich zunächst bewusst zu machen, was man nicht oder zumindest noch nicht leisten kann.

Das lassen wir lieber erstmal

In diesem konkreten Fall betrifft das vor allem die rechtssichere Dokumentation.

Kommerzielle Lösungen gewährleisten diese durch Zertifikate, Rechtekonzepte und revisionssichere Archivierung. Teilweise können selbst lokale Administratoren nachträglich keine Änderungen mehr vornehmen.

Bei einem selbst aufgebauten Server auf Basis von Open-Source-Software existieren diese Einschränkungen in der Regel nicht. Man kann Systeme zwar so konfigurieren, dass nur Administratoren Daten löschen dürfen und Einsatzdaten zeitnah beispielsweise auf eine M-Disc archiviert werden, jedoch bleibt offen, ob dies im Streitfall gerichtsfest wäre.

Daher gilt vorerst:

Für alle rechtlich relevanten Dokumentationen wird weiterhin die durch Leitstelle oder Kommune vorgegebene Fachsoftware genutzt.

Wozu dann der ganze Aufwand?

An dieser Stelle kommt meist die ernüchterte Reaktion:

„Toll. Einsatztagebuch, Funkprotokoll und Patientendokumentation fallen weg. Was bleibt dann noch übrig?“

Mehr als man zunächst denkt.

Denn eine nicht vollständig rechtssichere Dokumentation ist im Zweifel immer noch besser als gar keine. Zudem lassen sich Protokolle bei Bedarf ausdrucken und händisch unterzeichnen.

Gerade Einheiten, die ihre Dokumentation bislang noch handschriftlich führen, könnten bereits mit Open-Source-Tools eine deutliche Verbesserung erreichen.

Für die weitere Zieldefinition gehe ich jedoch davon aus, dass für den klassischen Dokumentationsalltag bereits funktionierende Windows-Lösungen existieren. Der Schwerpunkt liegt daher zunächst auf Aufgaben, die indirekt mit Dokumentation zusammenhängen.

Ziele

1. Schnelle und übersichtliche Lageinformationen

Nach einer Alarmierung besteht nahezu immer ein Informationsdefizit. Besonders ausgeprägt ist dieses bei nachrückenden oder sekundär alarmierten Einheiten.

Die Software des ELW soll den Zugführer dabei unterstützen, dieses Defizit schnellstmöglich zu reduzieren, Lageinformationen zu bündeln und übersichtlich darzustellen.

2. Informationen und Disposition eigener Kräfte

Der ELW soll Einsatzkräfte digital erfassen, Statusinformationen sammeln und strukturiert darstellen.

Darüber hinaus soll es möglich sein, unterstellte Einheiten gezielt zu disponieren, Aufgaben zuzuweisen und Verfügbarkeiten nachzuhalten.

3. Mindeststandard für Zusammenarbeit mit fremden Einheiten

Bei größeren Einsatzlagen treffen regelmäßig Einheiten aufeinander, die sonst nicht zusammenarbeiten.

Die Abstimmung erfolgt häufig erst vor Ort. Das führt zu doppelter Dokumentation, Medienbrüchen und Zeitverlust.

Der Server soll hier einen gemeinsamen, niedrigschwelligen Arbeitsstandard bieten, über den Informationen geteilt und Kräfte koordiniert werden können.

Workflow

Die Ziele sind definiert, die Tools vorhanden. Jetzt fehlt der eigentliche Arbeitsablauf, der möglichst viele Prozesse automatisiert.

Ein möglicher Workflow könnte wie folgt aussehen:

1. Alarmierung durch die Leitstelle

• Idealerweise wird eine Zusatzalarmierung, beispielsweise über Alarmiator, direkt mit ausgelöst
• Alternativ kann ein DME ausgewertet oder der Alarm manuell im System erstellt werden

2. Datenübertragung an den ELW

Alarmiator übermittelt:

• Einsatzinformationen
• Stammdaten
• alarmierte Kräfte

Die Übertragung erfolgt automatisiert per MQTT an den ELW-Server.

3. Verarbeitung durch Node-RED

Node-RED übernimmt die zentrale Automatisierung:

• Anlegen eines neuen Einsatzes in NocoDB
• Erstellen eines einsatzbezogenen Channels in Mattermost
• Übergabe von Basisdaten an weitere Systeme
• Perspektivisch: automatisierte Darstellung einer Lagekarte

4. Operative Nutzung

• Mattermost dient der Kommunikation und Koordination
• Budibase kann für Formulare, Lagedarstellung oder strukturierte Eingaben genutzt werden
• Weitere Tools lassen sich modular ergänzen

5. Einsatzabschluss

• Datenexport
• Datensicherung (z. B. M-Disc)
• Systembereinigung / Server-Reset
• Vorbereitung für den nächsten Einsatz

Fazit

Der einfache Teil ist abgeschlossen.

Server aufsetzen, Container starten, Tools installieren. Das ist planbar und technisch lösbar.

Der eigentliche Aufwand beginnt jetzt:

Systeme miteinander verknüpfen, sinnvolle Workflows definieren, Automatismen schaffen und daraus einen echten Mehrwert für den Einsatzbetrieb entwickeln.

Oder anders gesagt:
Aus einer Werkzeugsammlung muss ein funktionierendes Einsatzsystem werden.