Prinzipiell können die Anforderungen an ein elektronisches Betroffenenerfassungssystem mit den Anforderungen an ein Warenwirtschaftsystem verglichen werden: Einer Einsatzleitung soll es möglich sein dafür zu sorgen, dass die richtige (verletzte) Person zum richtigen Zeitpunkt an den richtigen Ort gebracht werden kann. Allerdings werden elektronische Warenwirtschaftsysteme in definierten Umgebungen betrieben, wohingegen Betroffenenerfassung im nicht geplanten bzw. planbaren Einsatzgeschehen funktionieren muss.
Größere Lagen sind außerdem fast immer als zeitlich und örtlich verteilte Einsatzgeschehen zu betrachten. Einsatzkräfte treffen zeitversetzt ein, verschiedene Aufgaben werden von den jeweiligen Fachdiensten nach und nach wahrgenommen, und die Lage kann bedingt durch das eigentliche Ausmaß oder geographisch verteilte Einsatzabschnitte eine entsprechende räumliche Dimension haben.
Auch wenn die über die Betroffenen erhobenen Basisdaten (eindeutige ID, Sichtungskategorie, usw.) bei einem MANV einer Einsatzleitung zentral zur Verfügung stehen sollen, so erscheint eine völlig zentralisierte Datenhaltung wegen der inhärenten Dynamik des Einsatzes und der möglicherweise weiträumigen Ausdehnung nicht zweckmäßig. Hinzu kommt, dass drahtlose Kommunikationstechnologien im Freien zwar im Normalfall genügende Reichweite haben, die sich aber in ungünstigen Umgebungen (Gebäude, Tunnel, usw.) stark verringern kann.
Nahe liegender Schluss ist daher die Verwendung eines verteilten Datenbanksystems, das aus mehreren sich automatisch selbst synchronisierenden Instanzen besteht. Die einzelnen Instanzen werden sowohl auf den mobilen Erfassungsgeräten installiert, als auch auf Rechnern, die an den Kommunikationsknoten (z.B. WLAN-Accesspoints am Einsatzleitwagen, usw.) angeschlossen sind. Zusätzliche Instanzen des Datenbanksystems befinden sich auf dedizierten Servern in Rechenzentren im Internet, die über ein Webinterface von Krankenhäusern und Leitstellen abgefragt werden können.
Das Betroffenenerfassungssystem ist mit dieser Architektur voll skalierbar, auch wenn die automatische Replikation/Synchronisierung der Datenbankinstanzen zusätzliche Komplexität bedeutet. Folgende Betriebsmodi sind zu unterscheiden:
- Kontinuierliche Replikation zwischen Instanzen bei stabilen Netzwerkverbindungen.
- Ausfall und Wiederaufnahme einer Verbindung zwischen Instanzen (sowohl vor Ort mit mobilen Instanzen bei Verlassen/Wiedereintritt der Reichweite, als auch die WAN-Verbindung(en) zum Server im Internet), was eine Synchronisierung erfordert.
- Instanzen, die spät dem verteilten Datenbanksystem beitreten (z.B. neu eingeschaltete mobile Instanzen).
Im e-Triage Projekt wird die existierende Software Ingres Replicator zu einem möglichst ressourcenschonenden System weiterentwickelt, so dass der Betrieb in heterogenen schmalbandigen Netzen möglich ist, ohne dass anderer evtl. wichtigerer Datenverkehr (z.B. Sprache) beeinträchtigt wird. Eine weitere Herausforderung ist die Verwendung von Satellitenkommunikation im Projekt. Die weitaus größeren Signallaufzeiten erfordern sowohl angepasste Kommunikationsprotokolle als auch effektive Implementierungen von Replikations- und Synchronisationslösungen. Die Applikationen dürfen weder verschwenderisch mit dem zu übertragenden Datenvolumen umgehen, noch darf der Abgleich der Instanzen viele ausgetauschte Nachrichten erfordern, da ansonsten Vielfache der ohnehin großen Paketumlaufzeit des Satellitenlinks für den Abgleich notwendig sind.
Im Verbund werden diese Forschungsarbeiten vom Institut für Kommunikation und Navigation, Abteilung Digitale Netze, des Deutschen Zentrums für Luft- und Raumfahrt e.V. durchgeführt.
