Anlässlich meines Talks «Die Pandemie digitalen Scheiterns und neuer Hoffnung» auf der re:publica 2022 ein paar weitere Hintergründe, falls die beschriebenen Zusammenhänge noch ein paar Fragen aufwerfen.
Talk
Die Aufzeichnung des Talks gibt hoffentlich bald.
Slides
Die Slides gibt es unter bkastl.de/rp22
Zeitraum des Betrachteten
Der Talk beschäftigt sich im Wesentlichen mit meinen Erfahrungen aus digitaler Pandemiebekämpfung seit August 2020 bis heute. In dieser Zeit habe ich digitale Pandemietools in den Bereichen Kontaktnachverfolgung, Check-In-Apps, im Meldewesen nach Infektionsschutzgesetz und im Kontext Impfen betreut. Meine Erfahrung bezieht sich dabei auf die Arbeit in mehreren Gesundheitsämtern, aber auch auf die Erfahrung der Vernetzung auf Ebene einzelner Bundesländer.
Inhaltsverzeichnis
- Meldekette
- SORMAS
- Luca
- Corona-Warn-App
- InÖG
- IRIS connect
- impfterminservice.de
- sofort-impfen.de
- Impfen
Scheitern
Meldekette
Wie funktioniert eigentlich die Meldekette von Corona-Fällen? Nicht besonders direkt, die gezeigte Meldekette ist im Wesentlichen immer noch so wie vor ein paar Jahren, wenn auch mit mehr elektronischen Teilen.
Im Wesentlichen läuft das auch heute noch in etwa so:
- Indexfall fühlt sich krank und geht zum Test (PCR-Test im Folgenden relevant)
- Labor macht einen Test und schickt das positive Ergebnis via DEMIS elektronisch an das Gesundheitsamt (nein, kein Fax mehr, zumindest meistens)
- Gesundheitsamt importiert Daten in IfSG-System (oft SORMAS, teils SurvNet, teils was anderes)
- Gesundheitsamt nimmt Kontakt zur Person auf
- Gesundheitsamt meldet den Fall nach Erfassung aller relevanten Informationen via SurvNet an die nächsthöhere Behörde, meist ein Landesgesundheitsamt
- Landesgesundheitsamt meldet dann die gesammelten Fälle wiederum via SurvNet (also braucht es hier auf der Meldekette zwei verschiedene SurvNet-Instanzen) an das RKI
Das ist immer noch der sehr umständliche Prozess der Meldung von Coronafällen. Auch wenn es Möglichkeiten gibt, anonyme Daten aus DEMIS zu bekommen und auch wenn es Systeme gibt, die SurvNet-Meldungen ohne die Anwendung SurvNet selbst direkt senden zu können, ist aktuell immer manuelle Arbeit notwendig.
Der Prozess als solcher ist auch im Infektionsschutzgesetz mehr oder weniger so festgeschrieben, wäre im Sinne eines vollständigen digitalen Prozess zu etwa 80 Prozent der Fälle automatisierbar.
Wieso geht das nicht alles automatisch?
Naja, Labordaten sind in etwa 20 Prozent aller Szenarien nicht vollständig, das ist eher nur ein Erfahrungswert. Oftmals fehlen vielleicht Adressen von Indexfällen oder es fehlen Kontaktinformationen. Das muss dann ein Gesundheitsamt fehlende Infos recherchieren. Ohne Adresse lässt sich auch nicht herausfinden, wohin ein Fall genau gehört, von daher gibt es durchaus auch mal fehlgeleitete Labormeldungen.
Warum ist in dem Prozess der Labormeldungen ab und zu noch ein Fax beteiligt?
Grundsätzlich sind alle Labormeldungen eigentlich gesetzlich elektronisch (siehe Infektionsschutzgesetz) vorgeschrieben. Aber nicht alle Labore haben eine elektronische Anbindung an DEMIS, Schätzung bei 5 Prozent aktuell, die keine Anbindung haben, oftmals Kliniken. Das liegt nicht an den Laboren selbst, sondern an der Anbindung der Software der Laborinformationssysteme.
Um das etwas in den Kontext zu setzen: Laborgerätschaften sind oftmals sehr teure und komplexe Gerätschaften, deren Software ist komplex, kann nicht einfach so ausgetaucht werden und Anpassungen für ein System wie DEMIS, das ja eine deutsche Besonderheit ist, können sich ziehen.
Referenzen
- bkastl.de
Grundsätzlicher Zusammenhang der Schnittstellen - Gematik Wiki
Meldungsrouting in DEMIS - psu.edu
SurvNet@RKI - A Multistate Electronic Reporting System for Communicable Diseases von 2006
SORMAS
Was SORMAS in der gesamten Kette als IfSG-Fachanwendung überhaupt leisten kann
In der Außendarstellung zu SORMAS, dem Surveillance Outbreak Response Management and Analysis System werden oftmals Wunderdinge über SORMAS erzählt: Wird das Fax abschaffen. Endlich digitale Kontaktnachverfolgung. Automatisierung etc.
Das ist grundsätzlich alles etwas optimistisch, denn eigentlich gilt nach wie vor:
SORMAS ist vereinfacht gesagt eben so eine Datenbank mit User-Interface. Eigentlich sind alle Tools, die ich im Folgenden erkläre, Datenbanken mit irgendeiner Art von User-Interface.
SORMAS hat an sich das Ziel, Kontaktinformationen zu mit COVID infizierten Personen zu sammeln und visualisieren.
Man kann SORMAS zu Gute halten, dass es zumindest ein webbasiertes Datenbank-Tool ist, das sind nicht alle IfSG-Fachanwendungen, aber das allein reicht nicht.
Nun befüllt sich so eine Datenbank schlecht nur händisch, SORMAS braucht dazu Schnittstellen zu anderen Systemen, wie in der Meldekette weiter oben schon beschrieben.
Aktueller Nutzen von SORMAS gegenüber anderen IfSG-Fachanwendungen
Aktuell ist der Nutzen von SORMAS als IfSG-Fachanwendung eher gering, wenn schon eine gut nutzbare Fachanwendung vorhanden ist. Für Gesundheitsämter, die vorher mit Excel gearbeitet haben, ist es klar ein Fortschritt, für andere nicht unbedingt.
Denn die eigentlichen Features, mit denen SORMAS vermarket wurde, Austausch von SORMAS zu SORMAS (SORMAS2SORMAS) funktionieren noch gar nicht in dem Maße, wie das in einer Pandemie notwendig wäre.
Anbindung an DEMIS oder an SurvNet gibt es mit anderen System potenziell auch und zum Melden von Fällen nutzen viele Ämter dann wieder SurvNet, weil das die native Meldeplattform ist.
Die Krux mit den Schnittstellen
Der Witz darüber hinaus bei SORMAS war auch, dass SORMAS all die Austauschfunktionen nur im eigenen Ökosystem gedacht. Austausch zu einem anderen SORMAS? Klar. Austausch mit anderen Systemen? Uns egal. Sollen die Leute halt SORMAS nutzen.
Michael Ziemons, Gesundheitsdezernent der Städteregion Aachen beschreibt das passend mit: «Aus meiner Sicht wurden Weg und Ziel verwechselt.»
An dem «Von oben herab Aufzwingen» eines Systems, dass keinen guten Support für Schnittstellen zu bestehenden Systemen hat, krankt SORMAS nach wie vor.
Grundsätzlich kann SORMAS zwar über REST angesprochen werden und damit hat SORMAS zwar rein theoretisch «Schnittstellen», nur wurden diese immer so angelegt, dass zur Anbindung der eigenen SORMAS App gedacht waren, nie zur Vernetzung mit anderen Systemen.
(Und ja, ich hab das auch mehrfach 2021 konstruktiv versucht, auf eine Verbesserung in dem Kontext hinzuwirken. Erfolglos.)
Rein technisch kann eine Vernetzung von SORMAS auch nur mit einer zentralen Vernetzungsinstanz funktionieren, hier wird wahrscheinlich ein Umbau geschehen, den bisherigen Ansatz mit lokalen Trust Stores halte ich technisch für falsch. (IRIS connect hat zu eben dieser Vernetzung von Instanzen seit über einem Jahr einen zentralen Trust Store in einem dezentralen Netzwerk).
Es gibt übrigens noch andere Infektionskrankheiten…
… und nun kommt noch ein Haken bei der SORMAS-Euphorie. Aktuell ist die verwendete Version von SORMAS ist die Fassung speziell für COVID-19. Das heißt dann wiederum, dass Gesundheitsämter, die andere meldepflichtige Krankheiten bearbeiten, davon gibt es neben COVID einige, wie das Infektionsschutzgesetz zeigt, eine andere Software nutzen werden müssen als SORMAS.
SORMAS hat zwar Definitionen für andere Krankheiten, allerdings nicht in der aktuell vom Bund zur Verfügung gestellten Version. Das ist speziell für größere Gesundheitsämter ein Problem, weil hier die Verwendung zweier Systeme für den gleichen Aufgabenbereich notwendig wäre.
Die Sache mit dem Datenschutz
Aus den Tätigkeitsbericht diverser Datenschutzbehörden auf Länder- und Bundesebene liest man zwischen den Zeilen nicht unbedingt das beste Bild, dass SORMAS im Kontext Datenschutz und Technik macht. Da kann jetzt wieder das Argument "Der Datenschutz verhindert ja alles" kommen, nur ist es im Kontext des Infektionsschutzes so, dass das Infektionsschutzgesetz eigentlich schon eine sehr solide Basis zur Arbeit mit Daten bietet.
Was aus den von Datenschützer*innen im Umgang mit SORMAS durchaus deutlich wird, ist, dass hier viel Nachbesserungsbedarf nötig ist und war, was das Vertrauen in so ein System nicht unbedingt steigert.
Zugegeben, viele andere Systeme sind dort nicht unbedingt besser, allerdings wurden die auch nicht von oben herab für alle in Deutschland als das moderne System für alle auserkoren.
Es ist weniger, dass es Abstimmungen mit «dem Datenschutz» brauchte und auch nicht, dass diese Abstimmungen in einer Runde von Landesstellen und dem Bund gebündelt wurde, es ist eher der Zeitraum über den sich dieser Prozess zieht und auch die Punkte, die für ein professionelles Produkt dieser Größe, das mit durchaus sensiblen Informationen wie Vorerkrankungen hantiert, zumindest untypisch sein sollten. Ein Fehlen eines Kryptographiekonzepts, von Löschkonzepten etc. mindestens zu Beginn sollten bei einem Software-Produkt dieser Größe eigentlich nicht passieren.
Referenzen
- bkastl.de
Zur Thematik der Insellösungen und ihrer Notwendigkeit im Kontext SORMAS, Artikel im Wesentlichen nach wie vor gültig - kommune21
Weg und Ziel nicht verwechseln - Interview mit Dr. Michael Ziemons - gesetze-im-internet.de
Meldepflichtige Krankheiten nach Infektionsschutzgesetz - bfdi.bund.de
Bericht des Bundesdatenschutzbeauftragten von 2021 - lda.brandenburg.de
Tätigkeitsbericht Datenschutz 2021 der brandenburgischen Datenschutzbeauftragten - deutschlandfunk.de
Deutschlandfunk zur Digitalisierung im Gesundheitsdienst
Luca App
Keine weiteren Kommentare zur Thematik
Hier nur Referenzen zur Thematik.
Referenzen
- bkastl.de
Erläuterung, wie sich Infektionsrisiken in Daten abbilden lassen - bkastl.de
Erläuterung, welche Optimierungsmöglichkeiten es hinsichtlich digitaler Kontaktnachverfolgungslösungen gibt - geemco.de
Podcast zum Prozess der Kontaktnachverfolgung - mdr.de
Sachsen-Anhalt nutzt Luca-App: Zwei Mal - bundestag.de
Wie es um Sicherheit und Nutzen von Clustererkennungs-Apps steht (Fachgespräch im Bundestag) - bundestag.de
Nachholbedarf bei der Digitalisierung im Gesundheitswesen (Anhörung im Bundestag) - lucatrack.de
LucaTrack Exploit Demonstration - heise.de
Luca-App für Kontakt-Tracking: Sicherheitslücke in Schlüsselanhängern gefunden - media.ccc.de
Die Luca App - LucaTrack und andere Gefahren - Vortragsvideo - bkastl.de
Die Luca App - LucaTrack und andere Gefahren - Slides - ndr.de
Luca: Fehler im System - She likes tech Podcast - vimeo.com
Luca App: Nutzer greift Gesundheitsamt an und stiehlt Daten bevor er Ransomware schickt - golem.de
Luca-App ermöglichte Code-Injection bei Excel - workingdraft.de
Revision 486: Corona-Apps: Vorteile und Probleme am Beispiel der Luca App - Working Draft Podcast - landtag-bw.de
luca-App und Alternativen zur Kontaktnachverfolgung (Stellungnahme des Landtags Baden-Württemberg) - heise-devsec.de
Keynote: Die luca App – eine entschlüsselte Fehlersammlung (Vortragsankündigung) - bkastl.de
Die luca App - eine entschlüsselte Fehlersammlung - Kassel Edition (Slides) - luca.fail
Die Timeline zur Luca-App - heise.de
Expertin für Kontaktverfolgung: "Die Luca-App ist technologisch tot" - bkastl.de
Background: Digitalisierung. In einer Pandemie. Im Gesundheitsamt! - sr.de
Luca-App will Gastro-Dienstleister werden
Neue Hoffnung
Corona-Warn-App
Grundsätzlicher Erfolg der Corona-Warn-App
Zur grundsätzlichen Nützlichkeit der Corona-Warn-App verweise ich auf meine Aussagen im ADA 2021. Grundsätzlich halte ich die CWA nach wie vor von der Architektur her für das geeignetste Mittel, einer Pandemie auch mit sehr dynamischen Infektionsszenarien habhaft werden zu können. Direkte Teilhabe von Personen an einer Peer-to-Peer-Meldekette ist im Zweifel das geeignetste Mittel, in der aktuellen Situation überhaupt noch einen nennenswerten Effekt der Eindämmung erreichen zu können.
Zielsetzungen für Omikron
Oftmals höre ich Aussagen wie "Das bringt bei Omikron eh nichts mehr mit Apps". Das ist nicht ganz richtig. Bei der Eindämmung von Infektionen gibt es zwei grundsätzliche Strategien: Vollständiges Containment oder Mitigation.
Grundsätzlich kann die CWA auch bei schnell einsetzenden Virusvarianten wie Omikron einen Beitrag zur teilweisen Eindämmung (Mitigation) bieten, sprich es wird zumindest auch möglich sein, bei entsprechend infektiösen, aber möglicherweise asymptotischen Personen durch Warnungen im CWA-System eine Eindämmung zu erreichen.
Ob aber ein vollständiges Brechen von Infektionsketten im Sinne eines Containments erreicht werden kann, dass sollte wegen der Faktoren wie der Schnelligkeit von PCR-Tests oder Schnelltests vor Auslösen einer Warnung etwas eingeschränkt werden, das liegt aber weniger am System der CWA, welches im Rahmen der technischen Möglichkeiten das schnellste und stabilste System in entsprechender Größe bietet.
Ein Körnchen Salz
Das geht aber nicht ohne eine Pflege der weiteren Teile der Prozesskette zur CWA. Testinfrastruktur wird in digitaler Anbindung auch für den Herbst diesen Jahres mit hoher Wahrscheinlichkeit notwendig werden, allerdings zeichnet sich mit den Schnellteststellen gerade hier ein mittelfristiges Problem ab, wie ich bereits bei netzpolitik.org beschrieben habe.
Die CWA hat sich seit Ihrer ersten Version von Mitte 2020 zwar weiterentwickelt, aber ganz am Puls der Zeit ist sie nicht immer. Sinnige Funktion wie schnelltesttest.de kommen da schneller von der Zivilgesellschaft – aber immerhin besser als von Rappern. Eigentlich wäre sowas aber immer auch digitaler Service des Staates an seinen Bürger*innen.
Referenzen
- bundestag.de
Wie es um Sicherheit und Nutzen von Clustererkennungs-Apps steht (Fachgespräch im Bundestag) - bkastl.de
Aufzeichnungen und Antworten zum Fachgespräch im Bundestag 2021 - netzpolitik.org
Artikel zur Testinfrastruktur Mitte 2022 - schnelltesttest.de
Schnelltest Test - (link: https://netzpolitik.org/2022/hackerinnen-kollektiv-staat-soll-online-tool-fuer-schnelltests-unterstuetzen/ text: netzpolitik.org
Staat soll Online-Tool für Schnelltests unterstützen
Innovationsverbund Öffentliche Gesundheit
Warum wir gemeinwohlorientiert den Öffentlichen Gesundheitsdienst im Digitalen unterstützen
Weil wir alle ein Haufen digitalaffiner Menschen sind, die mit dem kaputten Zustand der Digitalisierung speziell im öffentlichen Gesundheitswesen frustiert sind. Der Artikel hat bisher ja wenig Positives zu vermelden, beschreibt aber gerade einfach nur den Status Quo.
Entstehung des InÖG und Fokus der Arbeit
Der InÖG entstand aus diversen Beteiligten des WirVsVirus-Hackathons, hat aber eigene Projekte im Anschluss begonnen, wie etwa IRIS connect oder das Impfprojekt. Zu Beginn hat sich der InÖG auch für den Einsatz von SORMAS eingesetzt, hat Migrationsleitfäden erstellt etc.
Grundsätzlich versuchen wir konstruktiv zu unterstützen, wo wir können, allerdings gibt es im Kontext der Digitalisierung des Gesundheitswesens zu viel zu tun und bei allen Beteiligten müssen wir immer den ehrenamtlichen Aspekt herausheben. Wie eben bei ehrenamtlichen Hilfsorganisationen auch. Eine Art Cyberhilfswerk für den ÖGD eben.
Die Projekte, an denen wir im Kontext Software-Entwicklung arbeiten, sind also als die Punkte zu sehen, wo wir am meisten Handlungsbedarf in der Gesamtbetrachtung sehen.
Referenzen
- inoeg.de
Webseite des Innovationsverbund Öffentliche Gesundheit - aerztezeitung.de
Artikel zur Entstehung des InÖG 2021 - netzpolitik.org
Zu den Hintergrunden im Kontext WirVsWirus
IRIS connect
Dank an
Hier zuallererst ein Dank an die Björn Steiger Stiftung für die großartige Unterstützung.
Dann gilt mein Dank dem InÖG, wie bereits beschrieben, und dem Team von IRIS connect, zu dem ich erst im Laufe der Entwicklung gestoßen bin, mit dem wir inzwischen Schnittstellen für Gesundheitsämter in der Kontaktnachverfolgung für vier Bundesländer stellten. Ebenso Dank an die digital affinen und geduldigen Gesundheitsämter, die die ersten Versionen von IRIS connect mit begleitet haben.
Hintergrund
Zur Geschichte von IRIS connect verweise ich auf entsprechenden Text von der Webseite:
Die Idee einer Datenschnittstelle ins Gesundheitsamt entstand mit den ersten Lösungen zur digitalen Kontaktdatenerfassung. Die meisten davon wurden im April 2020 im Rahmen des #WirVsVirus Hackathon der Bundesregierung initiiert. Viele dieser Lösungen waren im Rahmen der ersten Öffnungen im Sommer und Herbst 2020 im Einsatz - was fehlte, war ein sicherer und standardisierter Weg der Gästelistenübermittlung an die Gesundheitsämter. Oftmals gab es pseudo-digitale und datenschutzrechtlich bedenkliche Individual-Lösungen - wie z.B. den Versand von Excel-Listen per E-Mail oder das Faxen von ausgedruckten Listen.
Im Oktober 2020 schlossen sich mehrere Anbieter unter Federführung der Kölner recover-Lösung deutschlandweit zusammen, um Standards für den Datentransfer in die Gesundheitsämter zu definieren. Das war der Start der Initiative „Wir für Digitalisierung“, mit mittlerweile über 70 Teilnehmenden und einer breiten Anwendungsvielfalt.
Parallel startete ein ähnliches Projekt seitens des öffentlichen Gesundheitswesens - der neu formierte Innovationsverbund Öffentliche Gesundheit (InÖG) hatte die Idee, die von der Bundesregierung präferierte Fachanwendung SORMAS um eine offene Schnittstelle zu „Bürger-Apps“ zu erweitern.
Um alle Projektbeteiligten zusammenzuführen und mit gestärkten Ressourcen schnell zu einem Ergebnis zu führen, unterstützt die gemeinnützige Björn Steiger Stiftung seit Anfang 2021 die Finanzierung des IRIS connect Projekts als Hauptsponsor.
Teil des Teams von IRIS connect bin ich selbst seit Mai 2021, zwischenzeitlich als Verfahrensverantwortliche.
Wer soll das bezahlen, wenn der InÖG ehrenamtlich ist?
Das ist relativ einfach: Die Entwicklung hat die Björn Steiger Stiftung finanziert. Hier dazu der ausdrückliche Dank an die Steiger Stiftung, die so etwas mit uns möglich gemacht hat.
Das heißt aber auch, dass IRIS connect zwar einen ehrenamtlichen Impuls hatte, aber ein durch und durch professionelles Softwareprodukt ist. Inklusive all dem, was dazu notwendig ist (z.B. Begleitung durch externe Security-Firmen im Rahmen von Pentests, Threat-Modelling etc.).
Entwicklungsmodell und Unterschied zu anderen Anbietern
IRIS connect ist Open Source und wird im Open Development Verfahren entwickelt.
Die Länder, die IRIS connect einsetzen, zahlen im Prinzip nur die Betriebskosten für Server und Zertifikate sowie Kosten für Support und Softwarepflege. Den Betrieb von IRIS connect könnte der Staat auch vollständig selbstständig bewerkstelligen. Im Vergleich zu anderen großen kommerziellen Anbietern sind die Kosten überschaubar.
Ist IRIS connect auch nur ein anderes Luca?
Nein. Der beste Begriff zu IRIS connect ist m. E. n. am besten umschrieben als Vernetzungsbaukasten.
Im Prinzip ist IRIS connect nur die Schnittstelle zum Gesundheitsamt z. B. für Kontaktnachverfolgungslösungen, die App dazu liefert ein beliebiger Anbieter, der angebunden ist. Damit soll sichergestellt werden, dass sich viele schon bestehende App-Anbieter an eine sichere Plattform anbinden können und es eine gewisse Pluralität gibt.
Wir hätten ein besseres Luca bauen können, das hätte das Problem aber nicht gelöst.
Wir haben uns auch aktiv dafür eingesetzt, dass ein Check-in über die CWA gesetzlich möglich ist, auch wenn das wirtschaftlich betrachtet eigentlich unsere «Geschäftsgrundlage» gefährdet hat. Als zivilgesellschaftliche und ehrenamtliche Organisation waren wir da aber lieber Ermöglicherin der besten Lösung, auch wenn das zu Lasten unserer Lösung ging.
Gästelisten skalieren aber nicht wirklich bei der Kontaktnachverfolgung, oder?
Nein, tun sie nicht. Allerdings hat sich im Laufe des Frühjahrs 2021 herausgestellt, dass es politisch gewollt ist, entsprechende Gästelisten vorzuhalten. Dieses Problem lässt sich digital wahlweise in der Art Luca lösen, als ein zentraler Datenhaufen oder eben als pluralistische Anbindungsmöglichkeit wie IRIS connect. Von einer pluralistischen Anbindungsmöglichkeit bleibt nach der Pandemie wenigstens noch die Möglichkeit, andere Verfahren damit umzusetzen.
Architektur von IRIS connect
Gästelisten sind im Prinzip nur eine mögliche Anwendung von IRIS connect, dazu stellt IRIS connect rein technisch mehrere Komponenten zur Verfügung. Die Architektur ist grundsätzlich dezentral aufgestellt und leitet im Wesentlichen nur Daten auf Anfragen weiter. Vorgehalten werden die angefragten Daten nur im jeweiligen IRIS Client im Gesundheitsamt.Die Komponenten bestehen aus:
- dem IRIS Client für das Gesundheitsamt, der Daten empfangen und entsprechend aufbereiten kann
- Endpoint-Server-Komponenten, die es Anbietern ermöglichen, sich einfach in den Verbund zu integrieren und Ende-zu-Ende verschlüsselt miteinander zu kommunizieren
- zentrale Komponenten, wie etwa ein Verzeichnis der erlaubten Apps und eine Art Adressbuch für Locations
Möglich wird dadurch die schnelle und sichere Anbindung von Apps, das sichere Bereitstellen von Formularen für Bürger*innen und der sichere Datenaustausch von Clients oder Gesundheitsämtern untereinander.
Auf dieser Basis lassen sich auch andere Anwendungen realisieren, nicht nur Gästelisten. IRIS connect ist daher eher erst einmal öffentliche digitale Infrastruktur denn App. Nach Zero Trust Prinzipien und nach Stand der Technik.
Open Source in einer Pandemie in der Verwaltung betreiben
Geht. Aus meiner Erfahrung kann ich sagen, dass es auch in Verwaltungen möglich ist, aktuelle Technik in Verwaltungen einzusetzen, allerdings ist es wichtig, zwei Dinge mitzubringen. Ein sauberes Betriebsmodell (also wer steht 24/7 für Server etc. gerade, Telefonsupport etc.) sowie Flexibilität im Betrieb selbst.
IRIS connect steht aus einem zentralen Teil, den ein Kommunaldienstleister (die AKDB) betreibt und da muss man sich halt auf einen einigen können. Bei den Clients im IRIS-Verbund ist es eigentlich egal, weil wir das bewusst so konzipiert haben, dass Clients selbst gehostet oder fremd gehostet werden können. On Premise oder Cloud, je nachdem, was machbar ist oder in die IT Policy passt.
Die wir die Verbindungskomponenten wie den Client und die EPS-Komponenten selbst stellen und entwickeln, gibt es nach erfolgreicher Installation eigentlich wenig Probleme, das Gesamtssystem weiterzuentwickeln.
Referenzen
- iris-connect.de
Webseite von IRIS connect - github.com
Github Repo - github.com
Architekturschaubild - workingdraft.de
Revision 491: Dezentrale Architekturen - Working Draft Podcast - steiger-stiftung.de
Pressemeldung der Steiger Stiftung zum Launch
Impfterminsoftware
impfterminservice.de
impfterminservice.de als Bundeslösung und andere Lösungen
Nach Corona-Impfverordnung ist die Kassenärztliche Bundesvereinigung für die Bereitstellung einer Terminvergabe zuständig (gewesen). impfterminservice.de war in Folge die Terminplattform für fünf Bundesländer (u.a. Baden-Württemberg). Die sogenannte Bundeslösung. Es gab bereits im Vorfeld Bundesländer, die auf eigene Lösungen setzten, aus Gründen, die mir nicht bekannt sind, aber sowohl der Föderalismus als auch individuelle Anforderungen dürften eine Rolle gespielt haben.
Versuch der konstruktiven Unterstützung in Baden-Württemberg
Anfang Januar 2021 war ich noch bei einer kleinen Software-Firma in Stuttgart angestellt. Ich kann mich noch an die Situation erinnern, dass mein Chef damals so unzufrieden mit der Impfterminbuchung war, dass wir als Firma damals dem Sozialministerium Baden-Württemberg aktiv Unterstützung angeboten haben. Das war aber dann wegen der Bundeslösungsthematik nicht möglich, da ja gemäß Gesetz die kv.digital dafür zuständig war.
Blick von außen auf impfterminservice.de
Nach einem Blick auf den Projektbericht der kv.digital (danke für die Transparenz) stellt sich für mich das Thema mit etwas Abstand so dar, dass hier in wenig Zeit (das Problem liegt bei der Politik, wir alle wussten, dass wir uns sinnvoll auf Impfungen auch digital vorbereiten müssen) eine Riesenlösung gebaut werden musste und dann dafür keine andere Lösung übrig blieb, als eine Bestandslösung anzupassen und extrem zu skalieren. Mehr ging wahrscheinlich nicht, gut war das Ergebnis aber auch nicht. Das Blocken von Hilfe von außen (es gab da mehr Versuche wohl) ist angesichts der Laufzeit der Impfkampagne und der Relevanz nur teilweise nachvollziehbar.
Natürlich besteht die Gefahr, dass eine scheinbar «funktionierende» Lösung durch Veränderungen nicht mehr funktioniert, aber wirklich gut funktioniert hat die Lösung ja nun auch wieder nicht, vor allem eben prozessual. Und das eben in extremer Skalierung.
Referenzen
- kv.digital
Projektbericht der kv.digital zu impfterminservice.de - gesetze-im-internet.de
Corona Impfverordnung mit Grundlage für Terminplattformen - sbamueller.com
Artikel von Sebastian Müller zu Problemen mit impfterminservice aus verschiedenen Sichten
sofort-impfen.de
Dank an
Hier gilt mein ausdrücklicher Dank vor allem Andreas Dewes, der sich dem Thema angenommen hat und mit Kiebitz eine herausragende technische Lösung für den Anwendungsfall geschaffen hat – losgelöst von den Tätigkeiten des InÖG.
Grundidee von sofort-impfen.de
Die Grundidee, die sofort-impfen.de mitgebracht hat, war die digitale Vermittlung von Restimpfdosen. Beim Aufziehen von Impfstoffen bleibt im Normalfall bei COVID-Impfstoffen nur ein begrenzter Zeitraum möglich, in dem alle möglichen Impfdosen eines Vials verimpft werden kann
Kontakt mit dem Team von sofort-impfen.de
Mitte des Jahres war das Team von sofort-impfen.de an den Innovationsverbund Öffentliche Gesundheit (InÖG), bei dem ich gerade mit an IRIS connect arbeitete, herangetreten, mit der Bitte um Unterstützung im Bereich IT Security.
Grundsätzlich hatte sofort-impfen.de zwar gute Intentionen, aber aufgrund der schnell wachsenden Plattform ein paar durchaus abzusehende Probleme.
Im Prinzip ging die Unterstützung im «Bereich IT Security» dann soweit, dass es zu einem begleiteten Architekturwechsel weg von einer zentralen E-Mailsammelstelle zu einer datensparsamen dezentralen Architektur ging. Letztendlich war das in gewisser Weise ein Rescue Project eines Rescue Projects.
Nach Beratung im Bereich Software-Architektur und Vermittlung von Entwicklungskapazitäten (siehe oben) gab es im Folgenden keine weitere Kooperation von sofort-impfen.de und dem InÖG.
Ich verweise hierzu auf die Historie der Beteiligung in der Doku von Kiebitz selbst:
Kiebitz wurde ursprünglich von KIProtect als Auftragsarbeit für das Team von sofort-impfen.de entwickelt, auf Vermittlung des Innovationsverbunds öffentliche Gesundheit (InöG). Kernidee war die Schaffung einer dezentralen, privatsphäre-freundlichen Plattform für die Impfterminvermittlung. Initiale Ideen wurden u.a. von Lilith Wittmann und Bianca Kastl entwickelt, ein detailliertes Konzept wurde anschließend von KIProtect ausgearbeitet und ohne Beteiligung des InöG umgesetzt. Dieses Konzept wurde im Betrieb in wesentlichen Punkten angepasst und erweitert um die Vermittlung von Impfterminen noch robuster und zuverlässiger zu machen.
Referenzen
- kiebitz.eu
Webseite von Kiebitz (der Software) - sofort-impfen.de
Webseite von sofort-impfen.de (dem Impfportal von Sommer diesen Jahres) - github.com
Github Repo - workingdraft.de
Revision 491: Dezentrale Architekturen - Working Draft Podcast
Impfen
Dank an
Die SPRIN-D, das BSI, den BfdI, SysElven, infra.run, die f-i-ts, The Brettinghams, Allerzeiten, CISPA, die kbv, diverse Gesundheitsämter, persönlich ganz besonders benben von allerzeiten und Jürgen von der Antei, dem Rest des InÖG und auch hier wieder die Björn Steiger Stiftung für eine Anschubfinanzierung und den Arbeiten an einem Betriebsmodell.
Und ein Danke an eines der ungewöhnlichsten zusammengestellten Teams aus Expert*innen, die du in der Konstellation nicht mal kaufen könntest wahrscheinlich.
(Ja, wir meinen das ernst mit dem Thema, wie vielleicht auch aus den Danksagungen klar werden sollte)
Motivation
Die erste Impfkampagne hatte für Impfinteressierte grundsätzlich eher hohe Hürden zu einer Impfung zu kommen. Dass im Sommer 2021 versucht wurde, Impfen niederschwelliger verfügbar zu machen war eine strategisch richtige Entscheidung. Im Herbst 2021 kam dann aber an manchen Orten ein gegenteiliger Effekt zum Tragen: Niederschwelligkeit ohne Koordination und eine klare Übersicht führt dazu, dass z.B. Menschen lange im Regen stehen und nach vier Stunden Warten evtl. keinen Impfstoff mehr bekommen, wie etwa aus einem ZDF-Beitrag von November deutlich wird.
Grundgedanke
Im Prinzip ging es mir darum, endlich ein «Push für Impftermine» haben zu können. Also dass der Impftermin sich in deiner Nähe bei Dir meldet, nicht umgekehrt. Das alles per Opt-In klar, aber auf jeden Fall nicht so wie aktuell, wo Menschen bei der Suche von Impfmöglichkeiten allein gelassen werden.
Das ist eigentlich einfach, wenn alle Impfmöglichkeiten vernetzt sind und ein System mit internen Wartelisten nach regionalen Gebieten (z.B. PLZ) getrennt sind.
Einblick in die Impfplanung
Impfen wie in der Corona-Pandemie ist eigentlich in der Masse nicht wirklich langfristig planbar, weil der Impfstoff wirklich final nur etwa eine Woche voraus planbar ist, da der Impfstoff ja erst just-in-time produziert werden muss. Das deckt sich auch mit meiner beruflichen Erfahrung aus dem Gesundheitsamt, ja wir haben da auch mit großen Impfzentren in der Logistik und Planung zu tun. Das führt in Hochphasen wie der Boosterimpfungszeit im Herbst absehbar immer wieder zu Situationen, in denen eine verteilte und vernetzte Planung wichtig ist, zumindest an der Stelle der Impfstellen.
Diese Planung wurde im Herbst allen Impfstellen eigentlich selbst überlassen. Da Impfen aber ein gesamtgesellschaftliches Problem ist, sollte es eine gemeinsame, öffentliche und vertrauenswürdige Plattform geben, die hier bei der Übersicht und Vernetzung unterstützt. Im Prinzip kann es egal sein, ob eine Person bei einer ärztlichen Praxis, in einem Impfzentrum oder von einem mobilen Impfteam geimpft wird, wenn hier eine dynamische Verteilung stattfinden kann.
Anpassung an die Impfkampagne im Herbst 2021
Dazu haben wir das technische Basis von sofort-impfen, Kiebitz also, adaptiert. Der Grundgedanke von Kiebitz war hier von den Grundakteuren im System schon hervorragend geeignet, weil es hier bereits drei mögliche Akteure im System gibt: Impflinge, Impfstellen und Mediatoren. All das ist bereits in einem Ende-zu-Ende-verschlüsselten Konzept abgebildet (ja, auf dem datensparsamen und sicheren Level geht das da).
Das heißt, dass es technisch bereits möglich ist, dass Dachorganisationen (z. B. Krankenkassen, Apothekerkammern, Gesundheitsämter) ihre Impfstellen im System validieren und freischalten können, die Impfstellen ihr Terminangebot selbst verwalten können und nur die Impfstelle und der Impfling wissen, was gebucht wurde.
Das heißt auch, dass die Abhängigkeiten, wie sie eigentlich auch in der Realität bereits organisatorisch vorhanden sind, vollständig über das System abgebildet werden können. Im Unterschied zu privatwirtschaftlichen oder anderen Konzepten ist es dabei nicht mehr nötig, dass Impfstellen einzelnen auf der Plattform freigeschaltet werden müssen, was Aufwand und Sicherheitsprobleme bringt, sondern dass hier Dachorganisationenen diese Tätigkeit übernehmen können. Heißt in der Praxis: Wenn eine Krankenkasse eines Bundeslandes allen ihren Ärzt*innen Zugang zu dieser Plattform geben möchte, kann sie das digital in Eigenverantwortung tun. Ebenso Apotheken, Impfzentren etc.
Ja gut, aber wer soll das in der Größe bezahlen?
Wir haben dankbarerweise von der Steiger Stiftung zumindest eine Anschubfinanzierung bekommen, damit sich Menschen im Team zumindest finanziell abgesichert voll dem Thema widmen konnten – also quasi Vollzeit entwickeln konnten. Der Rest des Teams hat das ehrenamtlich beigetragen.
Der vorliegende Stand ist eher als Proof of Concept zu sehen, der in einer kleinen Kommune zum Start lauffähig wäre (mit den Spezifika der Impfkampagne vom Herbst).
Den Betrieb und eine Qualitätssicherung für eine Plattform dieser Größe und Relevanz muss aber eine staatliche Institution letztendlich entweder einkaufen oder entsprechend stellen.
Ist das in der Größe denn teuer?
Von der Code-Entwicklung nicht wirklich, das Betriebsmodell wäre auch überschaubar – zumindest in Relation zu anderen Digitalprojekten in dieser Pandemie. Grundbedingung ist aber, dass die Verbände, die sich an eienr solchen Plattform beteiligen möchten, ihre Verifikations- und Kommunikationsstrukturen mit einbringen. Dass diese Verbände also über ihre gesicherten oder etablierten Strukturen Zugänge zum System verschicken.
Das können wir als zivilgesellschaftliche Organisation wie dem InÖG zumindest begleiten, das geht aber halt nur gemeinsam.
Ja aber Datenschutz
Finden wir total wichtig. Deshalb haben wir ein Ende-zu-Ende-verschlüsseltes System gebaut, dass gar keine personenbezogenen Daten speichert. Dann ist es für den Datenschutz einfacher sowas gut zu heißen. Es ist kein Zufall, dass ich auf den Slides das Logo des BfDI verwenden konnte.
Allerdings braucht ein Projekt dieser Größe dennoch weiter entsprechende Begleitung.
Ja aber, dann kann man ja einfach einen Termin so wegbuchen
Das ist ja auch das Prinzip dahinter. Natürlich gibt es aber im System eingebaut entsprechende Schutzmaßnahmen gegen Massenbuchungen. Idealerweise sehen wir eine App als Trust-Anker in dem System, ebenso als Kommunikationskanal. Alternativ wäre SMS eine Option, um Buchungen abzusichern, E-Mail oder andere personenbeziehbare Daten würden wir vermeiden wollen.
Eine Verifikation, ob eine Person medizinisch für eine bestimmte Impfung geeignet ist, muss ohnehin immer vor Ort durchgeführt werden.
Sind damit Pushnachrichten zu Impfterminen möglich
Prinzipiell ja. Auch das ist von Seiten des Datenschutz unkritisch, weil dabei nur eine Nummer «gezogen» wird, eine App oder ein anderer Kommunikationsrückkanal aber dann nur prüft, wann diese Nummer erreicht ist und dann entsprechend eine Pushnachricht ausspielt. Das ist quasi wie Nummer ziehen aufm Amt. Und das ist ja auch okay von Seiten des «Datenschutz».
Wenn das so toll klingt, warum gibt's das dann noch nicht?
Eine Impfterminsoftware auf Landes- oder Bundesebene ist eine überaus relevante Plattform, vor deren Einsatz alle Beteiligten viel Sicherheit brauchen, dass das funktionieren kann (im Sinne von Vertrauen in die Plattform). Dafür braucht es vorher viele kleine Testläufe z.B. auf kommunaler Ebene. Für einen Testlauf auf kommunaler Ebene braucht es aber dennoch wieder ein sauberes Betriebsmodell, was initial Kosten verursacht, die dennoch rentabel sein müssen. Letztlich waren wir zu dem Zeitpunkt, an dem ein Testlauf rentabel durchführbar war, noch nicht so weit von Vertragsstrukturen, die solche Plattformen brauchen. Als wir dann so weit waren, wars wieder nicht rentabel.
Pandemiesoftware hat auch viel mit dem richtigen Timing zu tun, das haben wir im Herbst nicht ganz getroffen.
Wie sieht das aus im Herbst 2022?
Wir können uns durchaus vorstellen, dass sich die Idee hoffentlich verfängt. Allerdings sind wir inzwischen auch noch etwas reservierter geworden mit unserem zivilgesellschaftlichen Engagement. Wir werden nur dann Lösungen gemeinsam mit Partnern entwickeln, wenn diese auch gewollt sind. Wenn es also einen offiziellen Auftrag oder Wunsch eines Bundeslandes, einer Kommune etc. gibt, sowas sinnvoll laufen lassen zu können, dann, aber nur dann, denke ich persönlich – und auch Teile des Teams, mit denen ich sprechen konnten – das wir das gemeinsam schaffen. Etwas neue Hoffnung habe ich doch immer wieder.
Referenzen
- github.com
Aktueller Projekstand
Epilog
Digitales Scheitern und neue Hoffnung in dieser Pandemie: Es ist nicht alles schlecht, aber es gibt viel zu tun. Stay safe!