Digitalisierung – was soll das eigentlich bedeuten?

Digitalisierung, Grundlagen, Netzpolitik

Bianca Kastl

Freitag abend machte Anne Roth auf Twitter folgende Feststellung:

Vielleicht fangen wir nochmal von vorne an und jemand definiert mal "Digitalisierung".

Okay. Versuchen wir mal zu umschreiben, was Digitalisierung eigentlich ist.

Wie sich die omniöse Digitalisierung platt definieren ließe

Ich könnte hier jetzt eine ziemlich platte Definition aus der Signalverarbeitung reinwerfen, die in etwa das Folgende enthält:

Digital ist die Repräsentation eines Signals durch zeitlich kontinuierliche und diskrete Werte.

Super Definition, Ende des Texts. Versteht nur wieder kein Mensch, geht am eigentlich Thema vorbei und politisch geht es ja schlagwortartig um alles und nichts, wenn Digitalisierung als Buzzword verwendet wird.
Ich könnte jetzt in einem anderen Fachbereich nach einer anderen Lehrbuchdefinition von Digitalisierung gucken, aber lasst uns das mal aus der Praxis ableiten, was Digitalisierung eigentlich sein kann, was aktuell darunter verstanden wird und was dazu eigentlich alles gehört. Fokus hier aber auf dem, was Politiker*innen uns wohl als Digitalisierung angedeihen wollen, was sie aber eigentlich im Bezug auf Verwaltung und Staat wohl eigentlich meinen (sollten).

Da ich zufällig seit einem Jahr nichts anderes als digitale Kontaktnachverfolgung mache und da ja quasi auch alles vom Fax bis zum Digitalen durchiteriert wurde, sollen mir mal vier Projekte aus dem Bereich als Beispiel dienen. Am Ende gibt es dann ein theoretisches Denkbeispiel aus dem Bereich OZG oder lang Onlinezugangsgesetz, wie sowas dann eigentlich richtig digital funktionieren würde – mit wahrscheinlicher Abweichung zu aktuellen Prozessen, auf die aber vielleicht trotzdem Digitalisierung draufgelabelt wird.

Digitalisierungsprojekte in der digitalen Kontaknachverfolgung

An den vier folgenden Projekten werden wir drei Wesensmerkmale für meiner Ansicht nach gelungener Digitalisierung herausarbeiten. Oder eben auch nicht, aber dazu dann im Detail.

SORMAS

SORMAS (Surveillance, Outbreak Response Management and Analysis System) ist das mit Erwartungen in Deutschland eigentlich gesetzte Kontakterfassungssystem unter Führung des HZI (Helmholtz-Zentrum für Infektionsforschung).

Elektrifizierung

Im Prinzip wurde hier ein ursprünglich analoger Prozess der Datenerfassung quasi elektrifiziert. Ich nenne das bewusst in Abgrenzung zu meiner Ansicht nach vollständiger Digitalisierung Elektrifizierung. Daten werden über eine Weboberfläche in eine Datenbank eingetragen und können dann visualisiert und ausgewertet werden. Das wurde vorher in Ämtern vielleicht tatsächlich in Akten eingetragen, nun geschieht das aber elektrisch bzw. manche nennen das dann digital und meinen das wärs dann mit der Digitalisierung. Wir halten also mal das Thema Elektrifizierung fest als Wesensmerkmal der Digitalisierung.

Datenaustausch?

SORMAS wurde eigentlich mit dem Argument aus einheitliche Kontaktnachverfolgungslösung für ganz Deutschland gesetzt, weil damit eigentlich ein Datenaustausch über mehrere Gesundheitsämter hinweg möglich sein sollte. Das ist bei Ausbrüchen ja durchaus wichtig, denn Infektionen halten sich selten an Landkreisgrenzen. Eigentlich wäre mit SORMAS also auch ein gemeinsamer Datenaustausch möglich gewesen – mittels SORMAS2SORMAS. Die Gründe, warum das knapp ein Jahr nach dem Beschluss zu SORMAS immer noch nicht möglich ist, sind eher bei den Umsetzenden zu sehen, denn bei den Nutzenden. Nein, der Datenschutz ist nicht schuld, beim Austausch sensibler Daten sollte das technisch und rechtlich schon stimmen.

Eigentlich wurde mit SORMAS also auch versucht, einen gemeinsamen digitalen Datenaustausch zu schaffen, der aber eine entscheidende Einschränkung aufweist: er steht nur Nutzenden von SORMAS zu Verfügung. Ja, es gibt (theoretisch) eine API, nur ist diese eher nur für interne Zwecke gedacht und lässt viele API-Standards vermissen.
Dieses Verhalten und die Anspruchshaltung, damit seine Software durchsetzen zu wollen, halte ich in einer digitalen Welt für nicht tragbar und schädlich. In einer weltweiten Pandemie muss es im Zweifel möglich sein, Daten medienbruchsfrei digital auszutauschen – auch zwischen unterschiedlichen Systemen. Und nein, CSV-Export ist kein sinniger Datenaustausch.

Mehrfache Schreiben an die Projektverantwortlichen, den Austausch von Daten mit anderen Systemen über eine bidirektionale Schnittstelle zu anderen Infektionsschutz-Anwendungen oder Drittanwendungen, bleiben seit dem ohne weitere Entwicklung. Zum Überfluss wurde die SORMAS API (eine Programmierschnittstelle, die das quasi mit Biegen und Brechen ermöglichen hätte können) aus Sicherheitsbedenken auch noch deaktiviert im Mai – die Unzulänglichkeiten von SORMAS sind aber eine andere längere Geschichte. Wir halten aber mal fest, dass ein gemeinsamer Datenaustausch ebenfalls Wesensmerkmal von Digitalisierung sein sollte, bei SORMAS aber nicht ist.

Prozesstransformation?

Den dritten Punkt, den ich ansprechen wollte, zeige ich am besten nicht an SORMAS. Denn letztlich führt SORMAS zu keiner wirklichen Transformation des dahinterliegenden Prozesses mittels digitalen Tools. Infizierte Personen werden immer noch per Telefon erstkontaktiert. Daten werden vielfach elektrisch eingetippt und immer noch zum Großteil von Gesundheitsamtpersonal erfasst und so weiter… der Prozess ist im wesentlichen immer noch identisch einem analogen Prozess.

Die Analogität des Prozess zeigt sich auch an der Meldekette, ein Beispiel aus Bundesländern mit Landesgesundheitsamt: Gesundheitsamt bekommt Labormeldung für SARS-CoV2 (immerhin digital via DEMIS), legt einen Fall an, fügt dem Fall diese oder mehrere Meldungen hinzu. Die Fälle eines Tages werden dann gebündelt als Fälle eines Tages an eine weitere Instanz weiter vermittelt. Das kann je nach Bundesland entweder ein Landesgesundheitsamt sein oder unter Umständen direkt das RKI. Allerdings kommen die Zahlen dann letztendlich nicht direkt von der Quelle, die die Daten eigentlich in der Fallbearbeitung erfasst, sondern von einer höheren Instanz. Ein elektrifizierter Aktenlauf, kein Echtzeitstand der Infektionen (das ginge theoretisch, ja), immer wieder fehleranfällig, etwa wenn ein Landesgesundheitsamt ausfällt.

Standardisierungsansätze

Dem DEMIS-Projekt, das sich um die Übermittlung der Labormeldungen kümmert, halte ich mal zu Gute, dass es etwas fortschrittlicher vom technologischen Stack ist und auch moderne Standards wie HL7 FHIR kennt. Aber aus Labormeldungen allein werden keine bestätigten Fälle. Zu bestätigten Fällen in der Statistik braucht es immer noch einen weiteren Schritt, der aber als elektrifizierter Meldeweg gestaltet ist. Fälle müssen aus SORMAS etwa aktiv gemeldet werden. Sie erreichen nicht nach bestimmten Kritieren automatisch den Status, an dem Sie in einen gemeinsamen Datenaustausch übermittelt werden könnten.

SORMAS ist eigentlich Open Source und da sollten sich so Probleme ja beheben lassen, wäre zu hoffen. Meine Erfahrungen mit Feature Requests sind aber eher sehr durchwachsen.

Zusammengefasst ist SORMAS also leider kein gutes Beispiel für gelungene Digitalisierung.

Corona-Warn-App

Beim Brechen von Infektionsketten nimmt die Corona-Warn-App eine zentrale Rolle ein. Der Prozess wurde dabei so ziemlich digital gedacht, wie es eben im Rahmen der technischen Möglichkeiten geht.

Prozesstransformation

Begegnungen werden über das Exposure Notfication Framework mittels Bluetooth automatisch erfasst und aufgezeichnet. Dieser Prozess läuft automatisch im Hintergrund.
Erkrankt eine Person, kann diese ihr Testergebnis teilen und andere warnen. Die Warnung an andere Personen wird dabei technisch gesehen gleichzeitig an beliebig viele Personen ausgespielt. Im Rahmen der technischen Möglichkeiten und den Anforderungen an Datenschutz und Informationssicherheit ist dieser Prozess die aktuell schnellstmögliche Möglichkeit, entsprechende Risikokontakte zu erreichen. Schneller als ein Gesundheitsamt im Normalfall und vor allem auch bei einer beliebigen Menge von Personen gleichzeitig.
Hier wurde mit digitalen Mitteln also ein Prozess grundlegend verändert – und zwar im Sinne des Ziels sogar zum besseren. Schnelle Warnung, Automatismus bei der Beteiligung und dennoch sicher und datensparsam.
Eigentlich ist die Corona-Warn-App im Kontext der Prozesstransformation der bestmögliche Outcome: Nutzende bekommen mit mehr Komfort einen schnelleren Service als sie mit analogen Mitteln je haben könnten.

Die Corona-Warn-App greift dabei auch zum Teil auf einen elektrifizierten Weg zurück – nämlich bei der Übermittlung der Testergebnisse aus dem Labor. Diese werden ja von den Laboren entsprechend an die Infrastruktur der CWA übermittelt. Der Rest dahinter passiert aber automatisiert.

Datenaustausch

Die Corona-Warn-App ist auch Teil eines größeren Datenaustauschs, der auf Standards basiert. Einerseits dem Exposure Notification Framework, dass von Apple und Google gleichermaßen unterstützt wird, andererseits gibt es länderübergreifende Austauschserver für Risikowarnungen für quasi ganz Europa (l'exception française, mon dieu).

Open Source, IT-Sicherheit und Datenschutz wird bei der Corona-Warn-App auch konsequent gelebt, da gibt es nichts zu meckern.

Als Digitalisierungsprojekt ist die Corona-Warn-App also ein sehr gelungenes.

luca App

Im Frühjahr dieses Jahres wurde die luca App vom Influencern des Unternehmens als eine Lösung zur Kontaktnachverfolgung via Check-ins in dieser Pandemie angepriesen. Meine Haltung zur luca App ist kritisch, weil sie ohnehin nur eine Nischenanwendung in der Kontaktnachverfolgung abdecken kann – die der Gästelisten. Dabei scheint luca für Außenstehende aber ein vermeintlich gutes Beispiel für Digitalisierung zu sein.

Elektrifizierung

Letztendlich handelt es sich aber nur um eine Elektrifizierung der Gästeliste. Mit etwas höherem Sicherheitsanspruch zwar, aber mit immer wieder auftretenden handwerklichen Mängeln.

Teil eines gemeinsamen Datenaustauschs ist luca ausdrücklich nicht. CSV-Export, ein paar CSV-Dialekte oder ein eher obskurer SORMAS-API-Call aus der Weboberfläche des luca Backends für Gesundheitsämter machen aus luca noch lange keine gut interoperable App. Letztendlich ist luca ein Vendor-Lock-in für ein paar Millionen Euro.

Vom Prozess her stellt die Umstellung auf luca keine wirkliche Prozessverbesserung dar. Denn: Daten müssen von Gesundheitsämtern abgerufen werden, und dann entsprechend manuell ausgewertet werden. Inzwischen bietet luca zwar eine etwas differenziertere Möglichkeit der Warnung über die App, es wirkt aber eher wie ein Nachbau der Corona-Warn-App – nur mit mehr Aufwand für alle Beteiligten, im Speziellen den Gesundheitsämtern.

Auch wenn der Code von luca offen ist, ist luca kein Open Source Projekt.

Als Digitalisierungsprojekt also kein gelungenes.

IRIS connect

Zum Thema IRIS connect muss ich vorwegschicken, dass ich da parteiisch bin, ich leite den Verfahrensbetrieb. Aber kurz zur Erklärung, was IRIS eigentlich macht: den Teil der Anbindung von Apps an Gesundheitsämter. Zumindest in vier Bundesländern, drei davon (Sachsen, Thüringen, NRW) sind keine klassischen «luca-Länder».

Im Wesentlichen liefert IRIS aber «nur» die Anbindung an die Ämter, nicht die Apps zum Anfassen. Mögliche Daten für die Anbindung an Gesundheitsämter sind Gästelisten oder Indexfalldaten (z.B. Übermitteln von Kontaktdaten). Das funktioniert so, dass sich eine App an IRIS anbindet und diese dann Anfragen über IRIS bekommt und beantwortet. Für ein Gesundheitsamt gibt es dann nur eine Oberfläche für alle Apps.

Elektrifizierung und Datenaustausch

In der beschriebenen Systematik deckt IRIS also die Bereiche Elektrifizierung (Daten müssen nicht mehr analog übermittelt werden) und Datenaustausch ab (ein Datenstandard für verschiedene Apps). Darüber hinaus bietet IRIS auch die Möglichkeit weiteren Datenaustausch zu ermöglichen, da die Komponenten Open Source sind und mit der Komponente des EPS (Endpoint Server) quasi alles fertig zur Kommunikation mitbringen.

Ich würde IRIS in diesem Kontext also eher als Digitalisierungsermöglichungsplattform zu sehen, aber die Beurteilung nehme ich wegen Subjektivität nicht vor.

Prozessuale Änderungen kann IRIS zwar ermöglichen, im aktuellen Kontext von Gästelisten gelten aber die gleichen Einschränkungen wie bei luca.

Keine Beurteilung von mir, weil Befangenheit.

Ebenen der Digitalisierung

Wir fassen zusammen: Im Kontext «Digitalisierung» gibt es mindestens drei Ebenen, die Digitalisierung in ihrem Wesen braucht, wenn sie gelingen will. Oder anders formuliert: wenn Digitalisierung auch einen positiven Impact haben soll.

  • Elektrifizierung (Nutzung digitaler Kommunikationswege und Dateneingabemöglichkeiten)
  • gemeinsamer direkter Datenaustausch (Nutzung einheitlicher Standards und Interoperabilität)
  • Prozesstransformation (Verbesserung des vorhandenen Prozesses durch digitale Tools)

Es gibt wenige Anwendungsfälle, bei denen eine dieser Anforderungen nicht berücksichtigt werden sollte, im Idealfall führt die Digitalisierung von Prozess X zu einer Verbesserung auf allen drei Ebenen. Und idealerweise ist der Code dazu transparent und kollaborativ, also echtes Open Source.

Anforderungen wie Datenschutz, Informationssicherheit, gute Benutzbarkeit und Barrierefreiheit sind wichtige Parameter bei der Umsetzung solcher Anwendung für Bürger*innen, aber nicht unbedingt Wesensmerkmale des dahinterliegenden Prozesses, der digitalisiert wird.

Implizit gelten die drei Wesensbereiche auch für Bereiche, bei denen Mensch vielleicht gar nicht daran glaubt, dass hier alle Bereiche tangiert werden.
Nehmen wir mal den wundgescheuerten (Wortwitz, sorry) Bereich wie flächendeckenden Mobilfunkausbaus und der Breitbandanbindung.
Wirkt zwar wie ein primär rein auf der Ebene der Elektrifizierung stattfindender Bereich, ist aber technisch ein eigener Datenaustausch (ganz abstrakt, vorher war da ja nichts) mit technischen Standards (gibt ja Standards für Mobilfunk oder Breitband), der Menschen eine Prozesstransformation auf einer Metaebene ermöglicht (Beispiel: Fernwartung von landwirtschaftlichen Maschinen, weil das jetzt erst durch entsprechend schnelle Internetanbindung möglich ist). Auf der Netzwerkebene ist dass eher weit weg von den eigentlichen Fachprozessen, aber dennoch Grundlage dafür.

Ein Beispiel aus der Praxis: ein Umzug, meinetwegen mit digitaler Unterstützung

Bild eines Umzuglasters mit einer Frau und einem Hund
Kommen wir zu einem letzten Teilbereich, das mit dem zwei P. Push und Pull. Aktuell ist vieles an z. B. Verwaltungsrozessen Pull. Sprich: ich als Bürger*in muss bittstellend beim Staate etwas fordern, um eine bestimmte Tätigkeit umsetzen zu können. Dazu versetzen wir uns mal in die Persona Diana, die umzieht von Stuttgart nach Frankfurt und die ein Auto hat und einen Hund namens Wauzi.

Angenommen, Diana zieht heute um, dann löst das eine ganze Kaskade von Tätigkeiten aus, die sie zu tun hat:

  • zum Bürgeramt gehen
  • Ausweis ändern lassen
  • Wohnsitz ummelden
  • Auto ummelden
  • Hundesteuer für Wauzi klären, wahrscheinlich Wauzi in Stuttgart abmelden und dann in Frankfurt anmelden
Bild eines sehr unbefriedigenden Prozesses, bei dem Diana alle Prozesse selbst anstoßen muss

Der Einfachheit halber lassen wir die Prozesse bei Privatunternehmen weg, Post ebenfalls, und Diana ist kinderloser Single. Im aktuellen Prozess hätte sie selbst mit digitaler Unterstützung drei verschiedene Behörden zu kontaktieren. Wir gehen mal davon aus, dass die Behörden zwar alle elektrifiziert im erwähnten Sinne sind, der jeweilige Datenaustausch aber segmentiert ist und die Prozesse halt so sind wie schon immer: soll Diana doch kommen, wenn sie was will. Im «Idealfall» findet sie immerhin Anwendungen dazu auf der Webseite der Stadt. Spoiler: im aktuellen Fall gibt es für Wauzi ein PDF und eine Webanwendung.

Wie das digitalisiert eigentlich aussehen könnte

Eigentlich müsste Diana in einem volldigitalisierten Ablauf nur zu verstehen geben, dass sie jetzt umgezogen ist. Ja, das wäre das einzige, was bekannt sein müsste.

Diana würde:

  • ihre neue Adresse angeben
  • für darauf aufbauende Prozesse unter Umständen Daten freigeben oder Zustimmungen erteilen müssen
Bild eines sehr befriedigenden Prozesses, bei dem Diana alle Prozesse nur einmal anstoßen muss und alles im Hintergrund passiert

Aber das wars. Zum Bürgeramt müsste Diana nicht gehen, denn sie hat ja bereits elektrisch mit dem Bürgeramt Kontakt aufgenommen. Sie würde sich noch in einer digitalen Form legitimiert haben, in Form einer ID (schwieriges Thema, geht aber auch ohne Blockchain-Foo). Die Behörde würde sich digital auch identifiziert haben. Diana würde ihre persönlichen Daten ja nicht irgendwem anvertrauen.

Abhängige Prozesse, die an Dianas Wohnort hängen, würde dann in einer Kaskade automatisch via Push auf Diana zukommen. Vielleicht gibt es ein paar Rückfragen. Wauzi hat Diana wohl mitgenommen, könnte aber auch sein, dass nicht. Aber wer würde Wauzi schon zurücklassen? Wauzi würde in Stuttgart abgemeldet und in Frankfurt angemeldet - automatisch. Dabei würden die beiden Behörden miteinander über einen gemeinsamen Datenaustausch sprechen.
Ihren physikalischen Ausweis würde Diana zwar physikalisch ändern müssen, ihre digitalen Meldedaten würden sich aber bereits an ihren neuen Wohnort angepasst haben. Das Auto würde vielleicht sein Kennzeichen behalten, die Adresse dahinter würde sich aber anpassen, aber vielleicht würde Diana als Option ein anderes vorgeschlagen werden.
Zum Ende würden Diana vielleicht noch Informationen auf der Steuererklärung vermerkt werden (ein Umzug ist ja steuerlich anrechenbar).

Diana müsste nicht mehr alle Aufgaben selbst Stück für Stück angehen müssen.

Es geht um den Gesamtprozess

Vom Pull zum Push. Digital. Datengestützt. Ein vollständig umgestellter, nutzungsfreundlicher Prozess.
Der Weg dazu ist konsequente Digitalisierung. In allen Wesensmerkmalen, die Digitalisierung ausmachen kann.

Das ist, was ich unter Digitalisierung definiere. Das Ganze, mehr als die Summe von Einzelteilen. Ein Prozess, welcher mehr als nur Technik umfasst, aber auf sinnvoller Anwendung eben dieser Technik aufbaut.

Um wieder auf die sperrige Definition der Signalverabeitung zurückzukommen. Digital ist zeitlich kontinuierlich. Und eben das ist Digitalisierung auch in ihrer Anwendung und Entwicklung: ein kontinuierlicher Prozess, der am Ende bessere Gesamterfahrungen für die Menschen ermöglichen kann.

Digitalisierung ist ein tiefgehender Prozess. Es ist aber kein Prozess, vor dem wir Angst haben müssen. Denn letztlich ist es ein Prozess der Veränderung, den wir gemeinsam als Zivilgesellschaft gestalten können. Zum Besseren. Packen wir es an.