Deutschland - Softwarepaket und Informationssysteme - Einführung MPI und DICOM/WADO (#IAP-0694)

Bestehende Infrastruktur - Health-Engine als Kernsystem - Seit 2019 produktiv in 4 Einrichtungen (3 Akutkrankenhäuser + 1 Rehaklinik) - Seit 2022 in 6 Einrichtungen (5 Akutkrankenhäuser + 1 Rehakli-nik) - 27 Primärquellen angebunden inkl. KIS-System - 36 Schnittstellen (standardisiert + proprietär) implementiert - >10,8 Mio HL7-Nachrichten p.a. verarbeitet (2,5 Mio ADT, 5,5 Mio MDM, 2,5 Mio ORU) - Technische Basis - Konzernweites Clinical Data Repository mit konsolidierten Patien-tendaten - Integrierte Workflow-Engine mit automatisierten Prozessen - Active Directory Berechtigungssteuerung mehrstufig implementiert - Eigenes Rechenzentrum mit 1st/2nd-Level-Support - HTML5-Komponenten zur Fremdsystem-Integration - Kritische Prozessintegrationen - Ausfallsystem für KIS mit regelmäßigen Kurvenbackups - Rechtssichere Langzeitarchivierung etabliert - Privatliquidation (PVS/PAS-Integration) aktiv - MDK-Prüfverfahren automatisiert - Patientenportal auf health?engine aufgebaut - Zuweiserportal integriert - Spezialfunktionen - PDF-Konverter mit OCR für automatisierte Dokumentenablage - Nomenklatur-Dienst für KDL-Code-Annotation - MS Office?Dokumentenverarbeitung implementiert - CSV-Importer und LabCenter integriert Die dargestellte existierende Instanz der health engine wird mit zwei weiteren internen Modulen ausgebaut: Das Modul des Master Patient Index (MPI) ist ein Anwendungssystem zur Verwaltung von Patientenidentitäten. Dabei hält der MPI Einrichtungs- und/oder Anwendungssystem-interne Patientenidentifikationsdaten verschiedener (dezentraler) Systeme in einer Datenbank unter einer eindeutigen Kennung (globale ID) vor. Er ermöglicht die Verknüpfung von Patientendaten und Duplikaten, die in den verschiedenen Anwendungssystemen erfasst werden, sodass eine eindeutige, system- übergreifende Identifizierung von Patienten ermöglicht wird. Das Modul zur Umsetzung von DICOM/Wado schafft die Möglichkeit, sämtliche Bilddaten in der health engine zentral abzulegen. Via der in der Lösung zentral bereitgestellten elektronischen Patientenakte ist der Zugriff auf die Bilddaten für alle Mitarbeitenden mit entsprechender Berechtigung möglich. Die health engine stellt dafür alle nötigen Komponenten bereit. Der DICOM-Knoten koppelt alle Modalitäten und PACS-Systeme bidirektional, unabhängig vom Hersteller. Das VNA (Vendor neutral Archive) sorgt für die Ablage im Patienten- und Fallkontext, den schnellen Zugriff und gewährleistet die gesetzliche Archivierung. Über den integrierten schnellen HTML5-Viewer können alle Bilder, Serien und Studien in voller Auflösung dargestellt werden. Vorliegend werden modulare Erweiterungen des Bestandssystems beschafft, bei denen keine Schnittstellen zum Bestandssystem erforderlich sein sollen. Der Auftraggeber ist der einzige Anbieter auf dem Markt, der eine solche modulare Lösung ohne Schnittstellen in seinem Leistungsportfolio aufweist. Nur durch die Festlegung auf das vorliegende Produkt, kann eine reibungslose Integration und somit eine effektive Systemsicherheit sichergestellt werden. Überdies werden Koordinationsschwierigkeiten minimiert sowie die zusätzliche Inanspruchnahme finanzieller und zeitlicher Ressourcen vermieden. Eine integrierte Lösung bietet betriebliche Vorteile wie einheitlichen Support, gesicherte Schnittstellenkompatibilität sowie ein geringeres Fehler- und Betriebsrisiko. Der Einsatz mehrerer Dienstleister birgt das Risiko von Kompatibilitätsproblemen, Datenverlust oder Fehlfunktionen, die nicht hinnehmbar sind. Unterschiedliche technologische Plattformen erhöhen die Gefahr, dass Daten nicht korrekt gesendet oder empfangen werden können. Im Bereich kritischer Klinikprozesse ist es jedoch essenziell, unnötige Schnittstellen zu vermeiden, um Fehlerquellen auszuschließen. Nur durch das fehlerfreie Zusammenspiel der Health-Engine und der unterschiedlichen klinischen Systeme kann sichergestellt werden, dass alle notwendigen Daten zwischen den Systemen ausgetauscht werden können. Hierbei handelt es sich nicht um eine künstliche Einschränkung des Beschaffungsbedarfs auf einen bestimmten Dienstleister. Die Immanuel Albertinen Diakonie kann die gestellten Anforderungen durch objektive und nachvollziehbare Gründe belegen und hat ihren Beschaffungsbedarf nicht willkürlich oder diskriminierend fest-gelegt. Der aufgezeigte Beschaffungsbedarf ergibt sich aus den Anforderungen zur Integration der klinischen Systeme. Die fehlerfreie Verknüpfung zwingend erforderlich, um die vollständige und zuverlässige Bereitstellung aller medizinischen Informationen sicherzustellen. Nur durch eine fehlerfreie Übertragung zwi-schen den Systemen, unter Einsatz der Health-Engine, kann die notwendige Dokumentation und Entscheidungsgrundlage für den Betrieb der durch das KHZG zu implementierenden Softwarelösungen sichergestellt werden. Fehler in der Daten-übertragung könnten schwerwiegende Auswirkungen auf die Patientenversorgung haben und sind daher unter allen Umständen zu vermeiden. Die Auftraggeber haben wettbewerbliche Alternativen eingehend geprüft und belastbar festgestellt, dass die Lösungen anderer bekannter Unternehmen für die Auftragsdurchführung nicht in Betracht kommen, da auf dem Markt keine modularen und tiefenintegrierten Konkurrenzlösungen existieren. Überdies besteht keine ver-nünftige Alternative oder Ersatzlösung zu der hier zu beauftragenden Lösung, was ebenfalls einer belastbaren Überprüfung unterzogen wurde. Dies ist insbesondere der Fall, weil eine tiefenintegrierte Lösung ausschließlich durch den Betreiber des Bestandssystems realisierbar ist (Modul des Ausgangssys-tems - keine Schnittstelle erforderlich) und Drittlösungen aus wirtschaftlichen und technischen Erwägungen ausscheiden (siehe sogleich unter). Der mangelnde Wettbewerb stellt somit nicht das Ergebnis einer künstlichen Einschränkung der Auftragsvergabeparameter da Im Einzelnen: Notwendigkeit der Erweiterung - Standortübergreifende Konsolidierung - Konzernweite Patientenidentifikation über alle Standorte zwingend erforderlich - Einheitliche Prozessabbildung für Datenverarbeitung und Stake-holder-Kommunikation - MPI Anforderungen - Systemübergreifende Stammdatenverwaltung bei mehreren KIS - Dublettenerkennung über Standortgrenzen hinweg - Tiefenintegration in health-engine für nahtlose Anwendererfahrung - Patientenportal-Anbindung für gebündelte Informationsanzeige für die Patient:innen - DICOM/WADO-Viewer Anforderungen - PACS Ausfallsystem - Browserbasierter Zugriff ohne lokale Installation - Portal-Integration (Patienten- und Zuweiserportal) erforderlich - CDR-Studienablage für konsolidierte Bildarchivierung im vorhan-denen CDR - Modalitätsunabhängige Bildanzeige (Röntgen, CT, MRT) - Compliance-Anforderungen - DSGVO-konforme Erweiterung der Datenverarbeitung - Gesetzeskonforme Archivierung medizinischer Bilddaten - Lückenlose Audit-Trails über alle Module - bereits implementierte mehrstufige Berechtigungskonzepte müs-sen übernommen werden Risiken bei Nutzung von Komponenten anderer Hersteller - Technische Inkompatibilitäten - Workflow-Engine-Bruch: die im CDR vorhandene Workflow-Engine kann weder für MPI nocht für DICOM/WADO genutzt werden - Datenbankarchitektur-Konflikt: Natives Datenmodell nicht nutzbar - Weitere Schnittstellen erforderlich: vorhandene Schnittstellen wer-den müssen neu gebaut oder angepasst werden - Active Directory: Berechtigungskonzepte uneinheitlich - Versorgungsgefährdung - Notfallszenario: fremde Komponenten erhöhen das Ausfallrisiko des Notfall-/Ausfallsystems - PACS-Backup-Ausfall: Bilddiagnostik im Notfall nicht verfügbar - Verzögerte Fehlerdiagnose: Koordination zwischen mehreren Her-stellern erforderlich - Wirtschaftliche Risiken - Neuimplementierung von Schnittstellen: Unverhältnismäßiger Auf-wand, wenn vorhandene SSTs genutzt werden könnten - Parallele Wartungsverträge: Anzahl der Vertragsparteien erhöht sich und damit der administrative Aufwand - Schulungsaufwand erhöht: Personal muss für mehrere Systeme geschult werden - Release-Inkompatibilitäten: mögliche Nacharbeiten bei Updates - Datenschutz-/Sicherheitsrisiken - Patientenverwechslungen durch Fehlerhafte MPI-Integration - Berechtigungskonzepte: Uneinheitliche Zugriffskontrollen - Audit-Trail-Brüche: Compliance-Verstöße bei Protokollierung - Verschlüsselungsinkonsistenzen an Systemgrenzen - Betriebsrisiken - Verschiedene Hersteller = multiple Fehlerquellen im Notfallbetrieb - Gewährleistungslücken: Keine eindeutige Verantwortlichkeit - Support-Fragmentierung: Mehrere Ansprechpartner erforderlich - Performanceeinbußen: Middleware-Overhead bei Fremdsystemen