Wer in Deutschland IT-Systeme entwickelt und dabei rechtlich auf der sicheren Seite sein möchte, muss eine Vielzahl an Standards einhalten. An diesen wird seit Jahren, teils seit Jahrzehnten, intensiv gearbeitet. Die Einführung neuer Regelwerke ist häufig langfristig geplant, zieht sich über mehrere Jahre und bindet erhebliche Ressourcen. Dabei ist eines auffällig: Die Anwendungsfälle, die diese Standards abdecken sollen, sind in der Regel nicht neu. Für fast alle existieren bereits seit Langem etablierte und praxiserprobte Lösungen – meist auf internationaler Ebene.

Trotzdem scheinen internationale Standards in Deutschland oder der EU oft nicht auszureichen. Statt auf Bewährtes aufzubauen, werden eigene nationale oder europäische Varianten geschaffen. Der Anspruch dahinter ist meist, es „besser“ und „sicherer“ zu machen als der Rest der Welt. In der Praxis bedeutet das jedoch, dass bestehende Konzepte neu verpackt werden. Etwas komplett neu zu entwickeln kostet Zeit und Geld – Ressourcen, die bei deutschen Standards häufig weniger in technische Innovation als in politische Abstimmungen, Gremienarbeit und Meetings fließen.

Die eigentliche Entwicklung soll dann möglichst schnell und günstig erfolgen. Gleichzeitig sind IT-Fachkräfte selten daran interessiert, funktionierende Konzepte neu zu erfinden. Das Ergebnis sind komplexe Konstrukte mit neuen Namen, umfangreichen Spezifikationen und schwer verständlicher Dokumentation. Allein die Namensfindung scheint oft schon ein eigenes Projekt zu sein.

Geht man tiefer in die technischen Details, stößt man jedoch immer wieder auf alte Bekannte. XRechnung basiert letztlich auf XML-Standards wie UN/CEFACT oder UBL von OASIS. KIM, der „sichere“ Kommunikationsdienst zwischen Ärzt:innen und Laboren, nutzt im Kern S/MIME. Qualifiziert signierte elektronische Rechnungen waren bereits vor Jahren nichts anderes als signierte PDFs auf Basis etablierter Kryptostandards. Neu ist daran meist nur das Drumherum.

Problematisch ist, dass diese Zusammenhänge selten offen benannt werden. Hinweise auf die zugrunde liegenden Standards sind oft gut versteckt und werden nie klar kommuniziert. Statt direkt auf öffentliche Spezifikationen zu verweisen oder die Unterschiede sauber zu erklären – etwa bei Pflichtfeldern oder Prozessen – wird alles in eigenen Dokumenten neu beschrieben. Das erschwert die Implementierung unnötig und kostet Entwickler:innen viel Zeit und Nerven.

Am Ende bleibt der Eindruck, dass enorm viel Arbeit und Geld investiert wird, nur um nicht zuzugeben, dass internationale Standards oft genauso gut sind – und in vielen Fällen seit Jahren voraus. Leidtragende sind vor allem diejenigen, die diese Vorgaben umsetzen müssen.