Öffentlicher Gesundheitsdienst: Zwischen digitaler Souveränität & Flickenteppich

Inhaltsverzeichnis

Der Öffentliche Gesundheitsdienst (ÖGD) umfasst kommunale und staatliche Stellen, die für den Schutz der Bevölkerungsgesundheit zuständig sind. Dazu gehören unter anderem Infektionsschutz, Trinkwasserüberwachung, Schuluntersuchungen und die Gesundheitsberichterstattung. Die Digitalisierung dieses Bereichs verläuft uneinheitlich: Neben offenen, nachnutzbaren Lösungen stehen proprietäre Fachverfahren. So ist eine heterogene IT-Landschaft entstanden.

Dabei werden derzeit erhebliche finanzielle Mittel, Zeit und Entwicklungskapazitäten darauf verwendet, den digitalen Flickenteppich weiter zu vergrößern, statt ihn zu ordnen. Der Föderalismus im ÖGD führt dazu, dass Länder und Kommunen jeweils eigene Systeme entwickeln oder beauftragen, die häufig nur für den eigenen Kontext funktionieren und kaum nachnutzbar sind. Statt interoperabler Bausteine entsteht so eine Vielzahl isolierter Lösungen, die weder technisch noch organisatorisch aufeinander abgestimmt sind. Aus Sicht vieler Praktiker wäre es daher effizienter, den Kommunen eine zentrale, unabhängige IT-Instanz vorzusetzen, die verbindliche Architekturen, Standards und Schnittstellen definiert und dafür sorgt, dass Digitalisierung im ÖGD harmonischer, nachhaltiger und ressourcenschonender erfolgt.

Mit dem „Pakt für den Öffentlichen Gesundheitsdienst“ stellte der Bund vier Milliarden Euro für die Modernisierung der rund 400 Gesundheitsämter bereit, davon 800 Millionen Euro für Digitalisierungsmaßnahmen. Der Förderleitfaden des Bundesgesundheitsministeriums (BMG) formuliert als Ziele digitale Souveränität, Interoperabilität und eine bundesweite Nachnutzbarkeit von Lösungen. Projekte sollen nach Möglichkeit als quelloffene Software mit freien Lizenzen umgesetzt werden. Der Quellcode soll in öffentlichen Repositorien bereitgestellt werden; Abweichungen von diesem Grundsatz müssen begründet werden. Offen bleibt allerdings, wie verbindlich diese Prinzipien tatsächlich durchgesetzt und kontrolliert werden. Das Bundesministerium für Gesundheit, das sich selbst für bisherige Errungenschaften für die Digitalisierung des ÖGD lobt, hat laut der Akademie für Öffentliches Gesundheitswesen bereits in Aussicht gestellt, Teile des Sondervermögens für die weitere Digitalisierung des ÖGD nutzbar zu machen.

Im Jahr 2024 zeigte eine Studie, dass ein erheblicher Teil der Fördermittel in eigenständige Landes- und Kommunalprojekte floss. Diese Vorhaben hatten oft nur eine begrenzte Anbindung an übergreifende Strukturen. Statt einer kohärenten Gesamtarchitektur entstand eine Vielzahl von Einzellösungen. Gleichzeitig existieren bereits offene Bausteine wie ein Leichenpass auf Open-Source-Basis in Schleswig-Holstein.

Open Source im ÖGD: GA-Lotse und weitere Ansätze

Ein häufig genanntes Positivbeispiel ist der GA-Lotse, der im Gesundheitsamt Frankfurt am Main im Einsatz ist. Die Plattform wurde in elf Monaten mit einem Team von mehr als 60 externen Entwicklerinnen und Entwicklern aufgebaut. Sie setzt auf eine Zero-Trust-Architektur und wurde mehrfach extern sicherheitsauditiert. Der Quellcode steht unter der AGPL‑3.0-Lizenz öffentlich zur Verfügung. Damit werden zentrale Förderziele – Open Source, Transparenz, Auditierbarkeit und Nachnutzbarkeit – nicht nur erwähnt, sondern technisch und organisatorisch umgesetzt.

Weitere offene Vorhaben finden sich in einzelnen Ländern. Neben dem Leichenpass in Schleswig-Holstein entstehen in Bayern mit dem „ÖGD‑Bürgerportal“ und dem „ÖGD‑Handbuch“ zusätzliche Open-Source-Anwendungen. Sie sollen perspektivisch von mehreren Verwaltungen gemeinsam genutzt werden, bleiben bisher aber eher Insellösungen.

Proprietäre Strategien und wachsende Marktkonzentration

Daneben gibt es eine Reihe proprietärer Beschaffungsstrategien, die häufig mit wachsender Marktkonzentration einhergehen. In Baden-Württemberg wurde die Fachanwendung „ÖGDigital“ an die Firma HBSN vergeben. HBSN wurde später von der Berliner Init AG übernommen, die laut Bericht der Welt gut mit Aufträgen der öffentlichen Hand verdient. Die Init AG tritt zudem in anderen Bundesländern als Dienstleisterin auf, etwa in Hessen oder als Projektmanagerin bei einer Vergabe in Thüringen. Dort betont das zuständige Ministerium, der Auftrag sei nicht von ihm an HBSN gegangen. Ein unmittelbarer Interessenkonflikt sei daher nicht feststellbar. In Bayern werden ebenfalls Module von Unternehmen aus demselben Firmenverbund entwickelt.

In Baden-Württemberg sind Quellcode und Verträge zu ÖGDigital bislang nicht öffentlich zugänglich. Anfragen nach dem Informationsfreiheitsgesetz wurden mit Verweis auf Geschäftsgeheimnisse abgelehnt. Das zuständige Ministerium verweist darauf, dass der Vertrag dem Land die vollständige Herausgabe des Quellcodes zusichert. Dies ermögliche eine spätere Weiterentwicklung in eigener Verantwortung oder durch Dritte. Man habe diesen Weg gewählt, um eine klare Governance-Struktur zu etablieren und Haftungsrisiken zu begrenzen. Nach Auffassung des Landes besteht keine Pflicht zum Einsatz von Open Source. Eine unzulässige Marktdominanz von Init sei nicht erkennbar.

Rheinland‑Pfalz modernisiert die seit den 2000er‑Jahren eingesetzte Fachanwendung mikropro health, eine proprietäre Standardsoftware für Gesundheitsämter, die primär im Kinder‑ und Jugendgesundheitsdienst zur Fall‑ und Verwaltungsbearbeitung genutzt wird. Nach Angaben des zuständigen Ministeriums sei der Einsatz von Open‑Source‑Komponenten dort nicht möglich, da es sich um die Weiterentwicklung eines bestehenden proprietären Produkts handle.

Sachsen entschied sich nach einer europaweiten Ausschreibung für die kommerzielle Lösung OctoWare der easysoft GmbH, eine proprietäre Fachanwendung für Gesundheitsämter, die insbesondere im Infektionsschutz zur Fall‑, Kontaktpersonen‑ und Meldeverwaltung eingesetzt wird. „Aufgrund der kurzen Projektlaufzeit sowie der hohen Anforderungen an kurzfristige Einsatzfähigkeit, Support, Haftung und Weiterentwicklung war es jedoch erforderlich, Rahmenbedingungen zu setzen, die auch kommerziellen Anbietern eine Teilnahme ermöglichen, die ihre Leistungen auf Grundlage bestehender, erprobter Softwareprodukte anbieten“, so eine Sprecherin des Staatsministeriums. Eigene Ressourcen für eine Eigenentwicklung stünden nicht zur Verfügung.

Die easysoft GmbH ist in der öffentlichen Verwaltung kein unbeschriebenes Blatt. In Berlin war das Unternehmen über Jahre Vertragspartner für eine Fachsoftware im Kinder‑ und Jugendgesundheitsdienst. Trotz laufender Lizenzzahlungen wurde die Lösung dort nie flächendeckend produktiv eingesetzt. Sie lief vorwiegend in Teilfunktionen, etwa zur Unterstützung der Eingangsschuluntersuchungen. Fachbereiche kritisierten wiederholt veraltete technische Grundlagen und eine eingeschränkte Anschlussfähigkeit an moderne, serviceorientierte Architekturen.

Diese Beispiele zeigen eine strukturelle Spannung: Politisch wird gefordert, offene und nachnutzbare Lösungen zu schaffen. Gleichzeitig binden Verträge die Verwaltungen oft eng an einzelne Anbieter und proprietäre Architekturen. Das gilt auch dort, wo Source‑Code‑Übergaben zwar vertraglich vorgesehen, aber nicht transparent dokumentiert sind.