Regulation as Code: Das Ende der Regulierung, wie wir sie kennen

Noch immer veröffentlichen die Regulierer Gesetze und Verordnungen als Text. So wie seit Tausenden von Jahren. Regulation as Code bedeutet einen radikalen Bruch mit dieser Praxis.

Ist es möglich, Gesetze in Algorithmen zu überführen? Warum wollte man dies tun? Wie sollten Sie sich als Regulierer, Hersteller, Behörde oder Benannte Stelle darauf vorbereiten?

Antworten liefert dieser Artikel.

1. Vorteile von „Regulation as Code“

a) Verständlichkeit, Klarheit, Eindeutigkeit

Tatbestände und Rechtsfolgen

Ein Gesetz ist dann eindeutig, wenn für jeden unmissverständlich klar ist, was die Tatbestände und was die Rechtsfolgen sind, die das Gesetz beschreibt.

Folgen unklarer Tatbestände und Rechtsfolgen

Gesetzestexte, insbesondere die Tatbestände, sind oft nicht ausreichend präzise, verständlich und eindeutig formuliert. Manchmal führt ein fehlerhaft platziertes Komma, manchmal ein Übersetzungsfehler, manchmal eine fehlende Definition dazu, dass die Bedeutung des Satzes nicht mehr dem Ziel des Gesetzgebers entspricht.

Zahllose Publikationen zeugen von diesem Mangel der Unklarheit, den sie versuchen zu beheben. Beispiele für solche Publikationen sind:

• Wissenschaftliche Fachartikel, z. B. in juristischen Fachzeitschriften
• Leitlinien (wie die MDCG und FDA Guidance Documents)
• Normen
• Gerichtsurteile

Regulatorischen Vorgaben, die als computerlesbare Algorithmen veröffentlicht werden, würden diese Unklarheiten und Uneindeutigen beseitigen.

b) Identifizierbarkeit von Anforderungen

Ein Computer-Algorithmus lässt sich mit einer eindeutigen ID eindeutiger identifizieren und referenzieren als das mit Gesetzestexten möglich ist:

Referenzen wie die folgende wären damit obsolet:

„MDR Anhang XIV, Teil A, Satz 1, Unterpunkt a), achter Spiegelstrich, letzter Nebensatz“ .

c) Redundanzfreiheit

Die regulatorischen Vorgaben überlappen sich sowohl untereinander als auch innerhalb der einzelnen Vorgabe.

Auch innerhalb der einzelnen Regularien gibt es Redundanzen. So fordert die ISO 13485 gleich an drei Stellen in fast buchstabenidentischen Texten die Validierung computerisierter Systeme.

Diese Redundanzen lassen sich mit „Regulation as Code“ beseitigen.

d) Konsistenz, Widerspruchsfreiheit

Widersprüche in gesetzlichen Vorgaben fallen nicht so leicht auf, solange sie in Textform publiziert sind. Leider gibt es diese Widersprüche nicht nur zwischen den Vorgaben aus verschiedenen Rechtsbereichen, sondern auch innerhalb der jeweiligen Rechtsbereiche.

Logikbrüche finden sich beispielsweise in der IEC 62304, in den Dokumenten des Team-NB und den Auslegungen von Landesbehörden.

Mit formal prüfbaren Algorithmen lassen sich solche Widersprüche aufdecken und beseitigen.

e) Vollständigkeit

Gesetze haben oft nicht den Anspruch, die Menge der Tatbestände vollständig abzubilden. Zumindest werden sie diesem Anspruch häufig nicht gerecht.

Mit „Regulation as Code“ sind Lücken identifizierbar.

f) Automatisierbarkeit

Die Qualität von Regularien lässt sich automatisiert prüfen

Die Automatisierbarkeit all der oben genannten Qualitätsaspekte (Vollständigkeit, Konsistenz usw.) ist ein weiterer Vorteil von Gesetzen, die als Algorithmen formuliert sind.

Regularien lassen sich automatisiert erfüllen und durchsetzen

Genauso relevant ist die automatisierbare Prüfung von Tatbeständen auf Konformität mit diesen regulatorischen Vorgaben. Beispielsweise können Algorithmen prüfen, ob

• die Klassifizierung von Medizinprodukten korrekt ist,
• alle sicherheitsbezogen Nutzungsszenarien in der Risikoanalyse untersucht werden,
• für alle Maßnahmen zur Risikominimierung eine Überprüfung der Wirksamkeit stattgefunden hat und
• für jedes Software-System mindestens eine Software-Freigabe erteilt wurde.

Diese Automatisierbarkeit ist eine Voraussetzung für eine „Real-time Regulation“, d. h. eine kontinuierliche, automatisierte und bei jeder Änderung von Inputs (z. B. Dokumenten) erfolgende Prüfung der Konformität.

2. Anwendungsbereich von „Regulation as Code“

a) Regulatorische Anforderungen

Um die Konformität von Medizinprodukten und Wirtschaftsakteuren vollständig prüfen zu können, müssen alle regulatorischen Anforderungen in Algorithmen überführt werden.

Dies umfasst:

• Regulatorische Rahmenwerke wie die EU-Verordnungen und die 510(k)-Verfahren der FDA
• Normen und Leitlinien
• Spezifische Prüfkataloge wie die AI-Guideline des Johner Instituts

Je spezifischer die Vorgaben sind, desto einfacher sind sie als Algorithmen abzubilden. „Regulation as Code“ funktioniert also bei Prüfkatalogen einfacher als bei allgemeinen regulatorischen Rahmenwerken.

b) Zusätzliche Anforderungen von Behörden und Benannten Stellen

Neben den gesetzlichen und normativen Vorgaben haben Behörden und Benannte Stellen das Recht, innerhalb eines Beurteilungsspielraums und eines Ermessensspielraums zu urteilen und dabei weitere spezifische Anforderungen zu stellen. Auch diese zusätzlichen Anforderungen müssen algorithmisch abgebildet werden.

c) Prozesse

Auch Prozesse fallen in den Anwendungsbereich von „Regulation as Code“. Für eine Umsetzung muss festgelegt werden, welche Prozesse bei welchen Organisationen auf Konformität geprüft werden müssen.

Zu den Prozessen, für die die regulatorischen Anforderungen in Algorithmen überführt werden sollten, zählt das Johner Institut beispielsweise:

• Erstellen und Prüfen der Technischen Dokumentation bzw. von Zulassungsunterlagen durch den Hersteller
• Überprüfung dieser Unterlagen durch Benannte Stellen (Review)
• Auditierung von QM-Systemen der Hersteller durch die Hersteller und die Benannten Stellen
• Ausstellung von Zertifikaten durch Benannte Stellen
• Marktüberwachung durch die Behörden

3. Herausforderungen und Limitierungen

a) Unbestimmtheit regulatorischer Anforderungen

Beabsichtigte Unbestimmtheit

An vielen Stellen hat der Gesetzgeber bewusst keine klaren Vorgaben gemacht. So verwendet er beispielsweise sogenannte unbestimmte Rechtsbegriffe.

Dem Gesetzgeber ist bewusst, dass ein Gesetz mit seinen begrenzten Mitteln (der Sprache) nicht allen denkbaren Sachverhalte erfassen kann. Je unbestimmter die Begriffe, desto mehr Spielraum bleibt bei der Anwendung des Gesetzes. Das ist also ein Vorteil.

Allerdings: Je unbestimmter die Begriffe sind, desto unklarer ist im Zweifel auch, was eigentlich gemeint ist. Das ist ein Nachteil.

Die Unbestimmtheit schmerzt die Medizinproduktehersteller vor allem auf der Seite des Beurteilungsspielraums (der „Wenn-Seite“): Es wird intern und mit Benannten Stellen und Behörden (zu) viel diskutiert, ob ein Dokument oder ein Produkt den regulatorischen Anforderungen genügt.

Eine Kategorie für solche unbestimmten Gesetze sind Finalnormen. Das sind Vorgaben, die nur die Ziele formulieren, aber im Gegensatz zu den Konditionalnormen keine Wenn-Dann-Regeln enthalten.

Ein Beispiel für die Forderung eine Finalnorm wäre:

„Die EU setzt sich dafür ein, dass allen Patienten der Zugang zu sicheren, bezahlbaren und wirksamen Medizinprodukten zur Verfügung steht.“

Beispielhafte Forderung

Regulation as Code erlaubt die Überprüfung, ob

1. Konditionalnormen im Widerspruch zu den Zielen stehen, die die Konditionalnormen formulieren,
2. es zu Finalnormen unbeabsichtigt keine Konditionalnormen gibt,
3. Konditionalnormen ohne Bezug zu einem Ziel geschrieben wurden, das mindestens eine Finalnorm festlegt.

Unbeabsichtigte Unbestimmtheit

Wenn Gesetze unabsichtlich so formuliert sind, dass unklar bleibt, was mit den Tatbeständen und Rechtsfolgen gemeint ist, entstehen Unsicherheiten. Das ist der Fall, wenn

• Definitionen fehlen, unvollständig oder widersprüchlich sind,
• Begriffe anders werden verwendet als im Alltag üblich,
• Tatbestände nicht geregelt sind,
• Sätze so formuliert sind, dass nicht klar ist, auf welchen Satzteil sich ein Tatbestand oder eine Rechtsfolge bezieht.

Diese Unbestimmtheiten aufzulösen und in Algorithmen zu überführen, ist nur möglich, falls

1. Gerichtsurteile, Publikation (siehe oben) sowie die Abstimmung mit Behörden und Benannten Stellen dabei helfen, diese Unbestimmtheiten in der Gesetzgebung zu beseitigen oder
2. der Gesetzgeber selbst diese Unbestimmtheiten beseitigt.

In jedem Fall muss das Ziel darin bestehen, unbeabsichtigte Unbestimmtheiten zu beseitigen.

b) Akzeptanz und Rechtssicherheit

Um die Regularien als Algorithmen abbilden zu können, müssen Lücken und „Unbestimmtheiten“ beseitigt werden.

Der Gesetzgeber und die Normengremien sind derzeit nicht in der Lage, in ausreichender Geschwindigkeit Lücken zu schließen und Vorgaben zu präzisieren. Wenn dies jedoch jemand anderes täte und damit die Interpretationshoheit übernähme, könnte ein Streit darüber entbrennen, wie verbindlich diese Ergänzungen und Präzisierungen sind.

Es wären Gremien notwendig, denen diese Autorität übertragen wird.

c) Kompetenz

Einen Satz zu schreiben, der eine Anforderung enthält, ist einfach. Diese Anforderung mit mathematischer Präzision in einen Algorithmus zu überführen, ist hingegen schwierig. Viele können oder wollen sich auch gar nicht so genau festlegen.

Dazu kommt, dass die Autoren dieser Algorithmen in der Lage sein müssen, in verschiedenen Hierarchieebenen zu denken und konsistente Vererbungshierarchien zu entwerfen. So muss beispielsweise die Forderung einer nationalen Behörde zu den nationalen Gesetzen und die zu den europäischen Regularien passen.

Das gilt nicht nur für „Regulation as Code“. Aber bei als Text formulierten Vorgaben sind solche Inkonsistenzen und Widersprüche nicht so offensichtlich.

d) Aufwand

Einmalige Überführung von Gesetzen in Code

Selbst wenn die Gesetzgeber ihre Regeln als Code beschreiben könnten und wollten: Der Aufwand, um die Gesetze und Regularien in Algorithmen zu überführen, ist nicht nur initial hoch. Auch die fortlaufende Weiterentwicklung ist aufwändig. Denn die Algorithmen müssen den sich ständig ändernden Stand der Technik reflektieren.

Das heißt aber nicht, dass der Aufwand für die Überführung der Regularien in Algorithmen höher ist als der Aufwand, den Tausende Medizinproduktehersteller betreiben müssen, um die Konformität ihrer Produkte und Organisationen zu prüfen.

Das Gegenteil ist der Fall: Die Algorithmen würden diese Prüfungen automatisieren.

Verfassen von Gesetzen als Code

Vor allem der Aufwand, künftige Gesetze sofort als Algorithmen zu veröffentlichen („Regulation as Code“), dürfte nicht höher sein als „Regulation as Text“.

Denn man sollte unterstellen, dass die Autoren ihre Vorgaben in jedem Fall präzise gedacht und formuliert haben.

e) Algorithmen benötigen Daten

Alle Algorithmen sind wertlos, wenn sie nicht genutzt werden. Algorithmen lassen sich nur dann nutzen, wenn sie mit dem notwendigen Input gefüttert werden.

Dieser Input muss als Daten in den richtigen Formaten und Datenstrukturen bereitstehen. Das heißt, dass Hersteller, Behörden und Benannte Stellen IT-Systeme benötigen, die auf die Algorithmen zugreifen können und sie mit dem entsprechenden Input füttern.

4. Umsetzung

a) Technologien für „Regulation as Code“

Formale Sprachen

Formale Sprachen, insbesondere Domain Specific Languages (DSL) eigenen sich, um die regulatorischen Vorgaben abzubilden.

Ein Beispiel dafür ist Catala, eine Sprache, mit der beispielsweise Teile des US-amerikanischen Steuerrechts beschrieben wurden.

Viele Regeln lassen sich mit Prädikatenlogik (First order logic) und damit mit Sprachen wie OWL formulieren.

Werkzeuge

Rule Engines erlauben es, Regeln zu definieren und deren Abhängigkeiten zu beherrschen.

Frameworks

Ein technologisches Framework muss nicht nur Hierarchien von Regeln ermöglichen, sondern auch erlauben, dass Anwender eigene Regeln ergänzen und bestehende Regeln überschreiben. Zudem muss es die innere Konsistenz der Regeln überprüfen.

Mit solche einem Rahmenwerk würde eine wichtige Voraussetzung für ein ganzes Ökosystem von „Algorithmen-Anbietern“ geschaffen.

b) Vorbereitung

Auf Seiten der Gesetzgeber und anderer „Regulierer“

Gesetzgeber und Normengremien sollten exemplarisch damit beginnen, ihre Vorgaben als Algorithmen zu formulieren. So entwickeln sie ein Verständnis für die Umsetzbarkeit, die Aufwände und die Gestaltung von Prozessen.

Diese Umsetzung bedarf einer begleitenden Forschung, um

• eine übergreifende einheitliche Sprache (Grammatik) zu definieren,
• Regeln für die Überführung von Regularien in Algorithmen festzulegen und
• Prozesse zu spezifizieren, mit den die Regeln erstellt, geändert, gelöscht, validiert und versioniert werden können.

Eine schrittweise Umsetzung ist somit möglich. Es bedarf keines „Big Bangs“.

Auf Seiten von Herstellern, Behörden, Benannten Stellen

Hersteller, Behörden und Benannte Stellen brauchen nicht so viel in die Forschung zu investieren wie die Gesetzgeber. Sie können direkt die Anwendung vorbereiten:

• Prozesse festlegen, die sie automatisieren wollen, z. B. die Prüfung der Technischen Dokumentation
• Daten identifizieren, die den Output dieser Prozesse bilden und geprüft werden müssen
• Datenmodelle für diese Daten festlegen
• Diese Datenmodelle in den bestehenden IT-Systemen (beispielsweise ALM-Systeme) umsetzen, d. h., diese Systeme entsprechend konfigurieren
• Schnittstellen an diesen Systemen schaffen, um auf die Algorithmen zugreifen zu können

c) Unterstützung durch das Johner Institut

Das Johner Institut unterstützt die digitale Transformation von Herstellern, Behörden und Benannten Stellen; insbesondere die Umsetzung der regulatorisch relevanten Prozesse, wenn es darum geht,

• strategische Ziele zu bestimmen, um die Vision einer Echtzeit-Regulierung (real-time regulation) zu erfüllen;
• Datenmodelle festzulegen, die notwendig sind, um die Algorithmen zu nutzen und damit die Disruption einer Echtzeit-Regulierung zu ermöglichen;
• regulatorische Anforderungen in Algorithmen zu übertragen.

5. Fazit, Zusammenfassung

a) Das ist keine Zukunftsmusik

„Regulation as Code“ bzw. die Überführung von Regularien in Algorithmen klingt nach Zukunftsmusik. Aber die Umsetzung hat begonnen. Beispielsweise überführt das Johner Institut Regularien in Algorithmen.

Dabei wird offensichtlich, dass auch auf diesem Gebiet das Pareto-Prinzip Anwendung finden sollte: Mit überschaubarem Aufwand lässt sich ein großer Teil manueller Prüftätigkeiten automatisieren.

Nun gilt es, die Hersteller bei der digitalen Transformation zu unterstützen und die Gesetzgeber auf diesen Weg zu bringen. Das wird ein iterativer und von der Forschung begleiteter Prozess sein.

b) Das ist der Schritt auf die nächste Ebene

Die Präzision der Algorithmik erzwingt nicht nur Präzision bei der Formulierung regulatorischer Vorgaben. Sie macht auch Fehler schnell und gnadenlos transparent.

Es liegt ein große Chance darin, diese Fehler schnell zu beheben – und auf technologische Trends zu reagieren.

Das setzt jedoch die Fähigkeit voraus,

• Ziele der Regulierung klar zu benennen,
• regulatorische Vorgaben an diesen Zielen auszurichten,
• diese Vorgaben als Algorithmen zu formulieren,
• diese Algorithmen schnell zu validieren und auszurollen.

Das wiederum bedingt ein regulatorisches Meta-Framework inklusive Prozesse und Systeme, um

• den Änderungsbedarf zu identifizieren und
• Änderungen an der Regulierung zu beantragen,
• diese Änderungen in Code zu überführen und
• anschließend schnell zu validieren
• und schlussendlich auszurollen.

Das erinnert nicht zufällig an Best-Practices aus der Software-Entwicklung.

c) Das ist das Ende der Fuzzyness

Oft verbirgt sich hinter unklaren, uneindeutigen und schwer verständlichen Gesetzen, Normen und Leitlinien nicht der Wunsch der Autoren, einer unabsehbaren Menge an Situationen (Tatbeständen) gerecht zu werden. Vielmehr sind diese Gesetze Zeugnis eines Mangels an Definitionen sowie an Präzision beim Denken. Es fehlt die Bereitschaft (oder Fähigkeit), die grauen Zellen beim Schreiben dieser Vorgaben ausreichend zu quälen.

Das Ergebnis ist offensichtlich: Eine „Fuzzyness“ an Regulierung, die zur Belastung für all diejenigen geworden ist, die diese Regularien befolgen und einfordern müssen.

„Regulation as Code“ ist das Ende dieser Unbestimmtheiten.

Gleichzeitig ist „Regulation as Code“ die Voraussetzung dafür, dass die Regulatorik in Geschwindigkeit und Präzision mit der Entwicklung der Technologie mithalten kann und nicht zum Hemmschuh der Innovation wird.

---

Das Johner Institut sucht Förderer für die Forschungsprojekte im Bereich LegalTech.