Das Problem der geteilten Dateninfrastruktur, an dem jedes behördenübergreifende Programm still scheitert

Interoperabilität ist das Wort, das in jedem bundesstaatlichen IT-Strategiepapier und in nahezu jedem Digitalisierungsplan eines Bundeslands auftaucht. Es taucht auch, ungelöst, in den Post-mortems von Programmen auf, die trotz jahrelanger Anstrengungen keine Daten über Behördengrenzen hinweg teilen konnten. Das Konzept selbst ist nicht kompliziert. Die Umsetzung schon, und die Lücke zwischen beidem kostet Verwaltungen konkrete Programmergebnisse.

Die konkrete Verwechslung, die man benennen sollte: Die meisten CDOs, die in den öffentlichen Sektor wechseln, halten Interoperabilität in erster Linie für ein technisches Problem. Standard auswählen, APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → bauen, fertig. In der Praxis wird der technische Layer als Erstes gelöst. Was Programme zerlegt, ist der Governance-Layer darunter: Wem gehört die kanonische Definition eines Feldes, wer darf eine Data-Sharing-Vereinbarung autorisieren, welche Behörde haftet, wenn ein Datensatz falsch ist, und wie geht man damit um, dass Behörde A das „Geburtsdatum“ seit 1998 als Freitextfeld erfasst.

Warum behördenübergreifende Datenprobleme auf dem Schreibtisch des CDO landen und nicht auf dem des CIO

In einem Privatunternehmen ist eine gescheiterte Datenintegration ein Kostenproblem. In einer Behörde ist sie ein Versagen der Leistungserbringung mit Namen daran. Wenn das U.S. Department of Veterans Affairs und die Social Security Administration Leistungsdaten nicht abgleichen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, verlieren Veteranen Leistungen, die ihnen zustehen. Wenn Jugendhilfe und öffentliches Gesundheitswesen keinen gemeinsamen Client-Identifier haben, kann ein Kind durch beide Systeme gleichzeitig fallen. Der CDO trägt für dieses Ergebnis eine Verantwortung, die der CIO nicht hat, denn der CIO verantwortet die Leitungen und der CDO das, was hindurchfließt.

Das Vergaberecht auf Bundesebene verschärft das. Nach der Federal Acquisition Regulation erfordern Data-Sharing-Arrangements zwischen Behörden häufig formale Interagency Agreements, manchmal Economy Act Orders, manchmal Memoranda of Understanding, deren Abschluss sechs bis achtzehn Monate dauert. Ein CDO, der sich in einem Haushaltszyklus auf eine behördenübergreifende Dateninitiative festlegt, ohne diesen Vergabezeitraum einzuplanen, verfehlt den Termin. Prüfer des Government Accountability Office kontrollieren, ob Data-Sharing-Vereinbarungen die in der Programmdokumentation beschriebene Nutzung tatsächlich abdecken. Tun sie das nicht, landet der Befund im Bericht und der CDO erklärt ihn dem Haushaltsunterausschuss.

Wie Dateninteroperabilität im öffentlichen Sektor wirklich funktioniert: die Mechanik

Die Architektur hat drei Layer, und sie müssen in dieser Reihenfolge bearbeitet werden, sonst fällt das Ganze auseinander.

Der erste Layer ist der semantische: sich darauf einigen, was ein Begriff bedeutet, bevor man sich darauf einigt, wie man ihn überträgt. Die US-Regierung hat das National Information Exchange Model (NIEM), ein Datenwörterbuch, das gemeinsame Elemente über Justiz, Gesundheit, Einwanderung und Katastrophenschutz hinweg definiert. NIEM schreibt keine Technologie vor. Es schreibt Bedeutung vor. Wenn eine County-Sheriff-Behörde und eine Gesundheitsbehörde eines Bundesstaats beide einen „incident“ mit NIEM-konformen Definitionen beschreiben, können sie Datensätze ohne eigene Übersetzungstabelle austauschen. Der Ansatz der Europäischen Union über das Joinup-Interoperabilitätsframework erfüllt eine vergleichbare Funktion zwischen den Verwaltungen der Mitgliedstaaten.

Der zweite Layer ist der technische: APIs, Datenformate und Übertragungsprotokolle. Die meisten Gesundheitsprogramme des US-Bundes verweisen inzwischen auf HL7 FHIR als vorgeschriebenen Standard für den Austausch von Gesundheitsdaten, ein Mandat, das über den 21st Century Cures Act formalisiert wurde. Medicaid-Behörden der Bundesstaaten, die FHIR-basierte APIs umsetzen, haben festgestellt, dass nicht der Standard selbst der Engpass ist; der Engpass ist, dass Legacy-MMIS-Systeme nie dafür gebaut wurden, FHIR-konforme Endpoints bereitzustellen, und ihr Ersatz kostet eine Größenordnung mehr als die API-Arbeit.

Der dritte Layer ist der rechtliche und governance-bezogene: Data-Sharing-Vereinbarungen, die festlegen, wer worauf zugreifen darf, auf welcher gesetzlichen Grundlage, zu welchem Zweck und mit welchem Audit Trail. Hier bleiben die meisten behördenübergreifenden Programme stecken. Jede Behörde hat ihre eigene Datenschutzabteilung, ihre eigene Auslegung des Privacy Act von 1974 und ihre eigene Risikotoleranz. Die Aufgabe des CDO ist es, diese Gespräche zu einer Entscheidung zu treiben, und nicht anzunehmen, die Rechtsabteilung erledige das eigenständig.

Ein konkretes Beispiel: Der Child Welfare Data LakeData LakeEin Data Lake ist ein zentraler Speicher, der große Datenmengen im Rohformat ablegt, von strukturierten Tabellen bis zu unstrukturierten Dateien, bis sie gebraucht werden.Vollständige Definition ansehen → der California Health and Human Services Agency, zwischen 2021 und 2024 aufgebaut, erforderte eine NIEM-basierte semantische Abstimmung zwischen County-Bewährungshilfe, staatlicher Pflegekinderhilfe und Medi-Cal-Daten, bevor eine einzige API geschrieben wurde. Die semantische Arbeit dauerte vierzehn Monate. Die technische Integration vier.

Wann geteilte Infrastruktur funktioniert und wann sie zur teuren Belastung wird

Geteilte Dateninfrastruktur zwischen Behörden ergibt Sinn, wenn Programme tatsächlich über den gesamten Lebenszyklus hinweg dieselben Klienten betreuen und nicht nur an einem einzelnen Kontaktpunkt. Arbeitsförderung, Wohnhilfe und öffentliche Gesundheit sind gute Kandidaten, weil dieselben Personen über Jahre durch alle drei Systeme zirkulieren. Ein gemeinsamer Identifier und ein gemeinsames Datenmodell zahlen sich über die Programmlaufzeit aus.

Es ergibt keinen Sinn, wenn die Begründung für das Data Sharing lautet: „Es wäre interessant, das zu kombinieren.“ Wer sich erst einmal ein vollständiges Bild davon verschafft, welche öffentlichen Daten bereits existieren, bevor ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → sich auf den Aufbau einer geteilten Infrastruktur festlegt, stellt oft fest, dass Verwaltungsdaten die Frage schon beantworten, ohne dass ein neuer Integrationslayer nötig wäre.

Die ehrlichen Tradeoffs, die CDOs vor der Festlegung auf eine geteilte Infrastruktur ausdrücklich benennen sollten:

• Der Governance-Aufwand skaliert mit der Zahl der beteiligten Behörden. Drei Behörden, die Daten teilen, erfordern etwa neun bilaterale Vertrauensbeziehungen, die gepflegt werden müssen, nicht drei.
• Geteilte Infrastruktur schafft geteilte Haftung. Kommt es zu einem Breach, wird jede Behörde, deren Daten im System lagen, im Incident-Report und in der Anhörung im Kongress genannt.
• Standards werden zu Ankern. Sobald fünfzig Counties einem Datenmodell folgen, erfordert eine aus guten Gründen nötige Änderung dieses Modells ein Change-Management-Programm, das Jahre dauern kann, ganz gleich wie technisch simpel die Änderung ist.
• Föderierte Modelle, bei denen Behörden ihre eigenen Systeme behalten, aber standardisierte Query-Endpoints bereitstellen, bewahren oft mehr Autonomie und politischen Rückhalt als zentrale Data Lakes, auch wenn sie architektonisch unsauberer sind.

Die Programme, die dauerhaft funktioniert haben, teilen ein Merkmal: ein benanntes Data-Governance-Board mit behördenübergreifender Besetzung, Entscheidungsbefugnis und veröffentlichtem Eskalationsweg. Technologie ohne diese Struktur ist nicht interoperabel. Sie integriert einmal und driftet danach still auseinander, bis die nächste Programmprüfung feststellt, dass die Datensätze nicht mehr zusammenpassen.

Interoperabilität zwischen Behörden ist ein Governance-Problem mit technologischem Ausdruck, nicht umgekehrt. CDOs, die die Reihenfolge richtig setzen, also Bedeutung definieren, bevor sie Leitungen bauen, und rechtliche Befugnisse sichern, bevor sie Code schreiben, bringen Programme zu Ende. Wer die Reihenfolge umdreht, verbringt die zweite Hälfte jedes Projekts damit, Vereinbarungen nachträglich auf eine Infrastruktur zu setzen, die ohne sie gebaut wurde.

Der vollständige Kurs zu diesem Sektor:Daten im öffentlichen Sektor & Nonprofit.