Projekt RPS-Enterprise

Methodik und Software für domänübergreifende Planung

Stand der Technik ist, dass im Gesundheitsbereich oftmals nur isoliert geplant wird und die existierenden Softwarelösungen keine dynamische, übergreifende Planung unterstützen. Die aus dem Industriebereich bekannten PPS Lösungen tragen aber der Dynamik im Gesundheitsbereich nicht Rechnung und können deshalb nicht sinnvoll eingesetzt werden (keine homogenen Werkstücke, kein Lager, variable Durchlaufzeiten, etc.)

Ebenso gibt es kein standardisiertes Kommunikationsprotokoll, das über den Austausch einzelner Termine hinausgeht. Zusammenhänge zwischen einzelnen Komponenten von Abläufen werden, wenn überhaupt, nur rudimentär in einzelnen Systemen isoliert behandelt. Die Abhängigkeiten (Mehrdimensionalität) dieser Pläne kann aber nicht zwischen autonomen, dezentralen Systemen kommuniziert werden. So wird etwa der Pflegedienstplan isoliert vom Dienstplan des ärztlichen Personals erstellt, die Planung der Operationssäle erfolgt wiederum unabhängig von der Personalplanung. Allein diese drei Komponenten stehen aber oftmals in ursächlichem Zusammenhang.

Die mehrdimensionale Planung, also die Planung von voneinander abhängigen Ressourcen wie Ärztedienstplan, Pflegeplan, OP-Belegung, Bettenaufenthalt, ist innerhalb einer Planungsdomäne (z.B. Station oder Klinik) gut verstanden und durch das vorhandene RPS System technisch realisiert. Dabei wird jedoch die dynamische Verplanung von gemeinsam benutzten Ressourcen, wie z.B. Zentral-OP, nicht unterstützt.
Im momentanen RPS System bedarf es einer starren Zuordnungsstruktur von Kapazitäten und Kontingenten, um die gemeinsam von mehreren Domänen benutzten Ressourcen verplanen zu können. Neben RPS gibt es aber weder ein Planungssystem, das die Mehrdimensionalität berücksichtigt, noch gibt es eine Lösung für domänenübergreifende Planung.

Ziel des Projektes "RPS-Enterprise" ist es, eine Methodik zu entwickeln, wie dieser flexible, domänenübergreifende Planungsprozess möglichst automatisiert realisiert werden kann. Die angestrebte Lösung soll

► bei der Terminsuche unterstützen, d.h. Terminvorschläge für den gesamten Patientenaufenthalt (stationär oder
ambulant) erstellen,

► den Workflow der damit verbundenen Terminverwaltung in den verschiedenen betroffenen Domänen
unterstützen (Terminanfragen, Verschiebungen, Terminfreigaben, Terminbestätigungen, etc.)

► die Planungsqualität (Termintreue, Ressourcenauslastung, Effizienz) erhöhen und

► den Planungsprozess nachvollziehbar machen (Prozessstandardisierung).

Parallel soll ein Softwaresystem entwickelt werden, das die Anwendung der angeführten Methodik unterstützt und die Komplexität der Zusammenhänge beherrschbar macht.

Abb. Zusammenspiel der Planungskomponenten von RPS-Enterprise

Als Basistechnologie sollen möglichst offene Komponenten und Standards verwendet oder geschaffen werden, um die Einbindung in vorhandene Systemarchitekturen zu erleichtern (CORBA, IIOP, SOAP sowie andere Standardkommunikationsprotokolle). Als technische Mittel werden anerkannte Programmiersprachen sowie bewährte Datenbanksysteme verwendet. Als Clienttechnologie sollen sowohl Thin-Clients, als auch Fat-Clients zum Einsatz kommen, ebenso wird eine Integration in Standarddatenbank-Lösungen angestrebt.

Das zu schaffende Softwaresystem soll auch eine Koordinationsinstanz und eine Backbonestruktur für die Kommunikation der einzelnen Planungskomponenten zur Verfügung stellen.

Um dies zu erreichen, wird ein definierter Prozess bzw. ein Regelwerk benötigt, unter welchen Voraussetzungen und Rahmenbedingungen (technisch, organisatorisch, etc.) eine derartige Kompensation durchgeführt werden kann und darf. Ebenso ist auch die Schaffung eines spezialisierten Kommunikationsprotokolls notwendig, das die benötigte Semantik unterstützt. Technisch werden dabei entweder bestehende, offene Protokolle erweitert bzw. ein neues Semantikkonzept für vorhandene Kommunikationsprotokolle (wie z.Bsp. HL7) geschaffen werden. Auch müssen vorhandene Planungssysteme angepasst werden, um miteinander kooperieren zu können.