Architektur · Technischer Bauplan
Der Bauplan des Klinikinfosystems
Ein Klinikinfosystem besteht aus drei Bausteinen: einer lokalen, schreibgeschützten Projektion (dem Satelliten), einem Append-Only-Journal für neue Einträge und einem idempotenten Sync-Gateway – eine Ergänzungsschicht je Station, kein KIS-Ersatz.
Klassische KIS-Ausfallsysteme arbeiten nach dem Batch-Prinzip: In festen Intervallen – häufig einmal je Nacht – wird ein Abzug des zentralen Datenbestands auf ein lokales System kopiert. Fällt das Krankenhausinformationssystem (KIS) aus, greift die Station auf diesen Spiegel zurück. Das Problem ist der Zeitpunkt: Der lokale Stand kann im ungünstigsten Fall knapp 24 Stunden alt sein.1
Für eine Station bedeutet das: frisch angeordnete Medikation, seit dem letzten Abzug aufgenommene Fälle und aktualisierte Befunde fehlen genau dann, wenn das System gebraucht wird. Zudem sind solche Ausfallspiegel meist rein lesend – neue Einträge lassen sich nicht rechtssicher erfassen, sondern werden auf Papier ausgewichen und später nachgetragen.
Der eigentliche Befund lautet daher: Ein reiner Notfallspiegel adressiert den Ausfall, aber nicht den Regelbetrieb. Was die Station braucht, ist eine laufend aktuelle lokale Projektion, die im Alltag produktiv mitarbeitet und neue Einträge per Append-Only aufnimmt – nicht ein passiver Abzug, der einmal am Tag erneuert wird. Wie sich diese Systemklasse begrifflich einordnet, beschreibt die Seite Definition des Klinikinfosystems.
Ein Klinikinfosystem zerlegt die stationsnahe Arbeitsschicht in drei klar getrennte Bausteine. Jeder Baustein hat eine eng umrissene Funktion und lässt sich mit etablierter, quelloffener Technologie umsetzen:
| Komponente | Funktion | Beispieltechnologie |
|---|---|---|
| Satellit | Lokale, schreibgeschützte Projektion der laufenden Fälle einer Station – laufend aktuell, nicht nur im Notfall aktiv. | SQLite mit WAL-Modus (Write-Ahead-Logging) |
| Journal | Append-Only-Ereignisprotokoll: Neue Einträge werden ergänzt, nie überschrieben – konfliktfreie Basis für den Abgleich. | Event Sourcing (Append-Only-Log) |
| Sync | Idempotentes Gateway: Gleicht Journal-Ereignisse opportunistisch mit dem KIS ab; Wiederholungen erzeugen keine Duplikate. | FHIR- / HL7-Gateway über ISiK |
Die Trennung ist bewusst: Der Satellit liest, das Journal schreibt, das Gateway vermittelt. Weil das Journal nur ergänzt und das Gateway idempotent arbeitet, entstehen beim Abgleich keine Sync-Konflikte – ein wiederholt übertragenes Ereignis wird schlicht erkannt und nicht doppelt verbucht. Die Grundlagen dazu erklären die Lexikonartikel Append-Only-Dokumentation und FHIR und HL7 einfach erklärt.
Das Satelliten-Modell fasst die drei Bausteine zu einer produktiven Arbeitsschicht je Station zusammen. Es umkreist das zentrale KIS wie ein Satellit den Planeten: eigenständig handlungsfähig, aber immer auf das führende System bezogen. Die folgenden Eigenschaften beschreiben, was diese Schicht im Betrieb leistet.
Das Satelliten-Modell
- Append-Only. Jeder neue Eintrag wird als Ereignis ergänzt, nie überschrieben. Das erzeugt eine lückenlose, nachvollziehbare Historie und vermeidet Sync-Konflikte beim Abgleich.
- Rechte im Behandlungszusammenhang. Zugriff wird je Station im Behandlungskontext vergeben, nicht als globaler Vollzugriff über alle Fälle – das verkleinert die Angriffsfläche spürbar.
- Opportunistischer Sync. Der Abgleich mit dem KIS läuft, sobald eine Verbindung verfügbar ist. Ist das Netz gestört, arbeitet der Satellit lokal weiter und synchronisiert später nach.
- ISiK-Anbindung. Das Gateway dockt über den verpflichtenden ISiK-Standard und FHIR an das KIS an, statt proprietäre Schnittstellen zu erzwingen – interoperabel und wartbar.
- B3S-Ausfallsicherheit. Weil jede Station eine eigene lokale Projektion vorhält, bleibt der Betrieb bei Ausfall des Zentralsystems handlungsfähig – ein Beitrag zur Ransomware-Resilienz im Sinne des B3S „Medizinische Versorgung".
Kein Ersatz für Ihr Krankenhausinformationssystem. Eine Ergänzungsschicht je Station, die die Stationsrealität ernst nimmt und die Angriffsfläche reduziert.
1 Der genannte Versatz von bis zu 24 Stunden ist ein illustrativer Beispielwert für ein typisches nächtliches Batch-Intervall, kein Studienergebnis. Der tatsächliche Versatz hängt vom jeweiligen Ausfallsystem und dessen Konfiguration ab.
Warum genügt ein Batch-Ausfallsystem mit 24-Stunden-Versatz nicht?
Ein Batch-Ausfallsystem spiegelt den Datenbestand nur periodisch und meist nur lesend. Bei einem Ausfall ist der lokale Stand bis zu einen Tag alt. Ein Klinikinfosystem hält dagegen eine laufend aktuelle Projektion vor und dokumentiert neue Einträge per Append-Only.
Ersetzt die Architektur das zentrale KIS?
Nein. Der Satellit ist eine Ergänzungsschicht je Station, kein KIS-Ersatz. Das zentrale KIS bleibt das führende System; der Satellit projiziert dessen Daten und synchronisiert neue Einträge über ein idempotentes Gateway zurück.
Wie dockt ein Klinikinfosystem an bestehende Standards an?
Über FHIR und HL7 für den Nachrichtenaustausch und über ISiK als verpflichtendes Andockprofil. So bleibt die Ergänzungsschicht interoperabel, ohne proprietäre Schnittstellen zu erzwingen.
- Definition: Was ist ein Klinikinfosystem?
- Klinikinfosysteme je Station: PIA, Kinder-Onkologie, Notaufnahme
- Rechtsgrundlagen: DSGVO, § 630f BGB und B3S
- Lexikon: Append-Only-Dokumentation
- Lexikon: FHIR und HL7 einfach erklärt
Kein Ersatz für Ihr Krankenhausinformationssystem. Eine Ergänzungsschicht, die die Stationsrealität ernst nimmt.