MRM als Datendrehscheibe – Warum Multi-Ressourcen-Management mehr ist als Terminkoordination
Was passiert, wenn das Klinikinformationssystem (KIS) ausfällt – durch Cyberangriff, technisches Versagen oder geplante Wartung? Während klassische Backup-Systeme auf Datensicherung setzen, bietet medsolv.MRM einen fundamentalen Vorteil: Als zentrale Planungs- und Steuerungsinstanz kennt das Multi-Ressourcen-Management-System alle Subsysteme, deren Schnittstellen und kann direkten Datenzugriff orchestrieren – völlig unabhängig vom KIS.
Da klinische Prozesse immer eine zeitliche Komponente haben und an konkreten Terminen, Aufgaben oder Ressourcen hängen, fungiert das MRM nicht nur als Koordinationswerkzeug, sondern als intelligente Datendrehscheibe. Es weiß, welche Untersuchung wann stattfindet, welche Systeme involviert sind und wie auf deren Daten zugegriffen werden kann. Dieser Vortrag zeigt, wie medsolv.MRM zur Business-Continuity-Komponente wird und warum moderne Kliniken ihr Ressourcenmanagement als strategisches Ausfallkonzept neu bewerten sollten.
Die unterschätzte Systemarchitektur
Multi-Ressourcen-Management wird in den meisten Kliniken primär als Werkzeug zur Termin- und Kapazitätsplanung verstanden. Doch diese Sichtweise greift zu kurz. medsolv.MRM ist in Wahrheit die zentrale Orchestrierungsschicht, die alle klinischen Subsysteme miteinander verbindet – und genau diese Architektur macht es zu einer hochspannenden Backup-Lösung bei KIS-Ausfall.
Warum klinische Daten immer eine zeitliche Komponente haben
Der entscheidende Unterschied zwischen einem klassischen Informationssystem und einem MRM liegt in der prozessualen Perspektive:
- Jede Untersuchung hat einen Termin – und dieser wird im MRM verwaltet
- Jede Behandlung benötigt Ressourcen – Personal, Räume, Geräte werden im MRM koordiniert
- Jeder klinische Datensatz entsteht im Kontext – einer geplanten Aktivität, die das MRM kennt
Das bedeutet: Während das KIS Daten speichert und verwaltet, orchestriert das MRM die Prozesse, die zu diesen Daten führen. Es weiß nicht nur, dass Patient X eine MRT-Untersuchung hatte, sondern wann, wo, mit welchem Gerät, durch welches Personal und in welchem System die Bilddaten liegen.
Das MRM als Systemkenner: Zugriff auf alle Subsysteme
Ein modernes Multi-Ressourcen-Management-System wie medsolv.MRM integriert sich mit zahlreichen Subsystemen:
- Bildgebung (PACS/RIS) – MRT, CT, Röntgen
- Labor (LIS) – Laboraufträge und Befunde
- Funktionsdiagnostik – EKG, Sonographie, Endoskopie
- OP-Planung und OP-Dokumentation
- Strahlentherapie und Onkologie
- Ambulante Sprechstunden und Polikliniken
- Physiotherapie und weitere therapeutische Bereiche
Für jedes dieser Subsysteme kennt das MRM:
- Die Schnittstellen (HL7, FHIR, REST-APIs, proprietäre Protokolle)
- Die Authentifizierungsmechanismen
- Die Datenstrukturen und Zugriffsmethoden
- Den Kontext: Welcher Termin führt zu welchen Daten in welchem System
Der KIS-Ausfall: Wenn die zentrale Datenbank streikt
Bei einem KIS-Ausfall – sei es durch Ransomware, Hardware-Probleme oder kritische Updates – bricht üblicherweise die zentrale Informationsversorgung zusammen. Klassische Notfallkonzepte setzen auf:
- Papierbasierte Prozesse (ineffizient, fehleranfällig)
- Ausfall-KIS wie TwinKIS (zusätzliche Komplexität, parallele Datenhaltung)
- Read-Only-Zugriff auf Backup-Systeme (keine aktive Prozesssteuerung)
medsolv.MRM bietet einen anderen Weg:
Szenario: Notfallbetrieb mit MRM als Datendrehscheibe
Situation: Das KIS ist ausgefallen. Der Klinikbetrieb muss weiterlaufen.
Was das MRM leistet:
- Terminplanung läuft weiter – Patienten können eingeplant, Ressourcen koordiniert werden
- Direktzugriff auf Subsysteme – Das MRM ruft Befunde direkt aus PACS, LIS, RIS ab
- Kontextuelle Datenbereitstellung – Zu jedem Termin werden die relevanten Voruntersuchungen, Laborwerte und Bilddaten aus den jeweiligen Quellsystemen aggregiert
- Prozesssteuerung – Aufträge können an Subsysteme gesendet werden (Laborauftrag, Bildgebungsauftrag)
- Dokumentation – Grundlegende klinische Dokumentation kann im MRM erfolgen und später ans KIS synchronisiert werden
Der Clou: Das MRM muss nicht alle Daten selbst vorhalten. Es kennt die Topologie der Datenlandschaft und kann gezielt auf die Systeme zugreifen, in denen die Daten nativ liegen.
Technische Voraussetzungen für MRM als Backup-Lösung
Damit ein Multi-Ressourcen-Management-System diese Rolle ausfüllen kann, sind folgende Faktoren entscheidend:
1. Unabhängige Infrastruktur
- Eigene Server/VM, getrennt vom KIS-Stack
- Eigene Datenbank (z.B. PostgreSQL oder Microsoft SQL Server bei medsolv.MRM)
- Redundante Netzwerkanbindung
2. Direkte Subsystem-Integration
- APIs und Schnittstellen zu allen relevanten Systemen
- Authentifizierung unabhängig vom KIS (z.B. via Keycloak/SSO)
- Caching-Mechanismen für kritische Stammdaten
3. Intelligente Orchestrierung
- Regelbasierter Zugriff: Welche Daten werden aus welchem System benötigt?
- Fallback-Logik: Wenn System A nicht antwortet, wird System B geprüft
- Audit-Trail: Alle Zugriffe werden protokolliert
4. Notfall-Workflows
- Vordefinierte Prozesse für den KIS-Ausfall
- Reduzierte Funktionalität, aber betriebsfähig
- Synchronisations-Routinen für die spätere KIS-Wiederherstellung
Warum diese Architektur heute schon existiert
Der entscheidende Punkt: Diese Architektur ist keine Zukunftsvision, sondern bereits implementiert – allerdings nicht als Notfallkonzept verstanden.
Moderne MRM-Systeme wie medsolv.MRM müssen für ihren regulären Betrieb bereits:
- Mit allen Subsystemen kommunizieren
- Patientendaten kontextbezogen abrufen
- Aufträge an verschiedene Systeme verteilen
- Verfügbarkeiten in Echtzeit prüfen
Die Nutzung als Backup-System ist daher keine neue Funktion, sondern eine strategische Neubewertung bestehender Capabilities.
Vorteile gegenüber klassischen Backup-Strategien
| Aspekt | Ausfall-KIS (z.B. TwinKIS) | medsolv.MRM als Backup |
|---|---|---|
| Investition | Zusätzliches System, separate Lizenz | Bereits vorhanden, Doppelnutzung |
| Datenhaltung | Parallele Datenhaltung, Synchronisation nötig | Zugriff auf Originaldaten in Subsystemen |
| Komplexität | Neue Benutzeroberfläche, Schulung | Gewohnte Umgebung, keine Umstellung |
| Aktualität | Abhängig von Sync-Intervallen | Echtzeit-Zugriff auf Subsysteme |
| Prozessabdeckung | Grundfunktionen | Volle Prozesssteuerung für Diagnostik/Therapie |
Herausforderungen und Grenzen
Realistische Einschätzung:
Ein MRM kann ein KIS im Notfall nicht vollständig ersetzen, aber es kann:
- Den diagnostischen und therapeutischen Betrieb aufrechterhalten
- Zeitkritische Prozesse (OP, Bildgebung, Labor) steuern
- Patientenfluss und Ressourcenauslastung managen
Grenzen:
- Keine vollständige elektronische Patientenakte
- Eingeschränkte administrative Funktionen (Abrechnung, Controlling)
- Keine Pflegedokumentation (außer terminbezogene Leistungen)
Aber: Für die ersten 24-72 Stunden eines KIS-Ausfalls – die kritische Phase – bietet ein MRM eine deutlich bessere Betriebskontinuität als papierbasierte Notfallprozesse.
Strategische Empfehlungen für Klinik-IT
- Inventarisierung: Welche Subsysteme sind direkt ans MRM angebunden?
- Schnittstellenprüfung: Funktionieren diese auch ohne aktives KIS?
- Notfall-Playbook: Welche Prozesse laufen im Ausfall über das MRM?
- Stammdaten-Caching: Kritische Patientenstammdaten im MRM vorhalten
- Schulung: Personal auf MRM-zentrierten Notfallbetrieb vorbereiten
- Tests: Regelmäßige Ausfallszenarien simulieren
Fazit: Paradigmenwechsel im Denken über MRM
Multi-Ressourcen-Management ist mehr als ein Terminkalender. Es ist die prozessuale Intelligenzschicht, die versteht, wie klinische Abläufe funktionieren, welche Systeme involviert sind und wie Daten zu Informationen werden.
medsolv.MRM zeigt: Wenn man die Architektur konsequent auf Subsystem-Integration und zeitbasierte Prozessorchestierung ausrichtet, entsteht ein System, das im Notfall zur Datendrehscheibe werden kann – nicht weil es alle Daten speichert, sondern weil es weiß, wo sie sind und wie man sie abruft.
In Zeiten zunehmender Cyberbedrohungen und steigender Anforderungen an Business Continuity sollten Kliniken ihre MRM-Systeme strategisch neu bewerten: Nicht nur als Effizienzwerkzeug, sondern als kritische Infrastrukturkomponente für den Notfallbetrieb.