Eine „Open-Code-Logik“ nach dem Vorbild von openCoDE/ZenDiS ist im deutschen Gesundheitswesen nicht nur denkbar, sondern in Teilbereichen strategisch naheliegend – wenn man sie nicht mit einem Open-Source-KIS verwechselt. Der Engpass ist weniger Technik als Governance: Haftung, MDR-Nähe, KRITIS-Security und 24/7-Betrieb erzwingen harte Scope-Grenzen, Security-Gates und institutionelle Trägerschaft. Wer „Public Money, Public Code“ ernst meint, muss im Gesundheitswesen vor allem Interop-Infrastruktur, Basis-IT und Referenzimplementierungen industrialisieren – nicht klinische Kernlogik.
Die zentrale Verwechslung: „Open Source“ ist kein KIS-Ersatzprogramm
Der Quelltext macht eine klare Unterscheidung, die in Debatten oft verschwindet: Open Code ist im Gesundheitswesen primär ein Souveränitäts- und Sicherheitsinstrument, nicht automatisch ein Ersatz für proprietäre Kernsysteme. Klinische Kernprozesse (z. B. Medikation, Order Entry, PDMS) tragen unmittelbare Patientensicherheits- und Haftungsrisiken. In MDR-nahen Bereichen wird aus „Community-Code“ faktisch „Managed/Commercial Open Source“, weil eine juristische Einheit als „Steward“/Hersteller Verantwortung, QMS und Post-Market-Pflichten tragen muss.
Konsequenz: Der sinnvollste Einstieg liegt dort, wo Standardisierung hoch, klinische Entscheidungslogik niedrig und Austauschbarkeit hoch ist.
Wo Open Code sofort Wirkung entfaltet: Unterbau, Interop, Datenplattformen
Der Executive-Brief priorisiert konsequent: OSS-first im Unterbau (Infrastruktur, Integration, Standards), Open Standards + Referenzimplementierungen für fachliche Schnittstellen – und strenge Ausnahmen für klinische Kernprozesse und Medizinprodukte-nahe Software.
Drei Felder stechen heraus:
- Interoperabilitätsinfrastruktur
FHIR-Tooling, TI-Gateway-Bausteine, Terminologie-Server und standardisierte Message-/API-Layer sind Commodity-fähig und stark standardisiert (im Material u. a. über ISiK/FHIR verankert). Hier reduziert Open Code Vendor-Lock-in nicht als Ideologie, sondern als Architekturprinzip („Interop-by-default“). - Basis-IT in KRITIS-Realität
IAM, Logging/SIEM-Integration, Monitoring, Backup, Policy-Enforcement: Es existieren etablierte OSS-Komponenten, die ohnehin in vielen Sektoren betrieben werden. Der Mehrwert entsteht nicht durch „kostenlos“, sondern durch Auditierbarkeit und Exit-Fähigkeit – vorausgesetzt, Security-Controls sind nicht optional, sondern Gatekeeper. - Referenzimplementierungen statt PowerPoint-Standards
Das Material argumentiert für staatlich finanzierte, produktneutrale Referenzimplementierungen (insbesondere für ISiK-Module): Hersteller können diese übernehmen oder eigene Implementierungen liefern – aber der Standard wird praktisch testbar. Das ist die pragmatische Variante von Plattformpolitik.
Die drei Risiken, die man nicht wegmoderieren kann
1) Patientensicherheit (Scope-Fehler ist der Kardinalfehler)
Der Executive-Brief formuliert explizite No-Go-Kriterien: Open Code ohne strikte Abgrenzung in klinischer Entscheidungsunterstützung bzw. MDR-nahen Klassen ist nicht „mutig“, sondern fahrlässig. Der Kernpunkt ist nicht, dass OSS „unsicher“ wäre, sondern dass Validierung, Traceability und Stewardship nicht verhandelbar sind.
2) Supply-Chain-Security (Log4j/XZ-Logik)
Das Material behandelt den realen Widerspruch: Transparenz erleichtert Angriffe auf Code-Ebene – und ermöglicht zugleich schnellere, überprüfbare Abwehr. Daraus folgt nicht „Open Source = sicher“, sondern: SBOM-Pflicht, CVE-Monitoring <24h, reproduzierbare/signierte Builds (SLSA-Zielniveau), Mindestscore für Projekt-Hygiene (OpenSSF-Scorecard). Ohne diese Gates ist Open Code im KRITIS-Kontext eine zusätzliche Angriffsoberfläche.
3) Governance-Vakuum (Fork-Sprawl ist ein Betriebskostenproblem)
Das Dokument benennt das typische Scheitern nicht technisch, sondern organisatorisch: Fragmentierung, Wartungslast, Security-Debt – verstärkt durch Underfunding-Muster (ZenDiS-Unterfinanzierung wird als Warnsignal herangezogen). Eine „Upstream-Only-Policy“ wird als Gegenmittel beschrieben: Verbesserungen müssen zurück in den Hauptzweig, sonst entsteht ein teurer Zoo aus Sonderwegen.
Governance ist der eigentliche Code: Warum ein „Nationaler Health-Code-Hub“ plausibel ist
Die zentrale Empfehlung im Executive-Brief ist der Aufbau eines Nationalen Health-Code-Hub (analog openCoDE, aber healthcare-spezifisch): Plattform + Trägerschaft + Quality Gates + Security-Framework + klare Scope-Policy. Als Ausgangsbasis wird eine bereits vorhandene Repo-Landschaft bei gematik genannt; zugleich wird kritisch markiert, dass dort häufig Spezifikationen/APIs dominieren, nicht notwendigerweise produktionsreife Implementierungen.
Entscheidend ist die Logik dahinter: Ein Hub wäre nicht „ein weiteres Git“, sondern eine Institution, die
- Qualitäts- und Security-Kriterien erzwingt (Badge-/Gate-System),
- SOUP-/MDR-Grenzen operationalisiert (was darf hinein, was bleibt draußen),
- Wartung und Incident-Response organisatorisch absichert,
- und Beschaffung/Betrieb auf Wiederverwendung statt Einzelverträge ausrichtet.
Ohne diese Institutionalisierung bleibt „Open Source im Gesundheitswesen“ eine Sammlung guter Absichten mit schlechten Betriebskennzahlen.
Strategische Implikationen: Was Entscheider jetzt zu tun haben
1) Scope politisch festnageln (und nicht später „aus Versehen“ ausweiten)
Setze verbindlich: Open Code zuerst für Interop-Infrastruktur, Basis-IT, Datenplattformen; klinische Kernprozesse und MDR-nahe Logik nur mit expliziter Stewardship-/QMS-Struktur.
2) Security-Gates als Eintrittskarte definieren, nicht als Nice-to-have
Verlange für kritische Komponenten: SBOM, kontinuierliches Vulnerability-Monitoring, signierte Builds, dokumentierte Incident-Prozesse und Mindeststandards für Projektgesundheit. Ohne diese Nachweise ist „Open“ lediglich „ungeregelt“.
3) Referenzimplementierungen finanzieren, um Interoperabilität zu erzwingen
Wenn ISiK-Pflichten bestehen, ist die strategische Hebelwirkung hoch: Referenzimplementierung bereitstellen → Zertifizierung wird prüfbar → Sabotage durch „Spezifikations-Compliance ohne Praxis“ wird schwerer.
4) Beschaffung umstellen: von Lizenzkauf zu Wartungs- und Weiterentwicklungslogik
Das Material betont, dass OSS nicht „kostenlos“ ist. Entscheidend ist, ob Verträge Betrieb, Pflege, Security-Response und Exit-Fähigkeit abbilden – sonst wird Open Code zur Schatten-IT.
5) Governance bauen, bevor man skaliert
Der Executive-Brief skizziert Next Steps in 30/90/180 Tagen (interministerielle Steuerung, Repo-Security-Assessment, Pilot-Referenzen, EVB-IT-Muster, Security-Framework). Der Punkt ist weniger der konkrete Kalender, sondern die Reihenfolge: erst Governance+Security-Grundlagen, dann Rollout.
Die Datenlage zur tatsächlichen OSS-Nutzung in deutschen Krankenhäusern wird im Material selbst als lückenhaft markiert; belastbare, flächige Erhebungen fehlen. Das ist relevant, weil ohne Nutzungstransparenz auch der Business-Case (TCO/Lock-in-Kosten) schnell zur Glaubensfrage wird.
Dialog
Wo liegt in deiner Organisation die reale Schwelle: Würdest du einen Health-Code-Hub unterstützen, wenn er konsequent Infrastruktur und Referenzimplementierungen liefert – aber klinische Kernlogik explizit ausklammert?
20.12.2025, Olaf Dunkel, https://www.olafdunkel.de
© 2025 Dieser Beitrag beruht auf eigenständiger Recherche und Analyse diverser Quellen; eine KI leistete lediglich sprachliche Unterstützung, die inhaltliche Verantwortung trägt ausschließlich der Autor.
Schreibe den ersten Kommentar