Foto: Google Gemini · AI-generated
In den meisten Softwareprojekten lautet die Frage, ob das System funktioniert. In regulierten Projekten gibt es eine zweite Frage, die genauso schwer wiegt: Können Sie in acht Monaten beweisen, dass es funktioniert hat — gegenüber einem Auditor, der nicht dabei war?
Diese zweite Frage klingt nach Papierkram. Sie ist es nicht. Sie verändert die Architektur.
Wenn ein Fehler ein regulatorisches Ereignis ist
Softwareteams haben eine eingespielte Sprache für Fehler. Etwas ist kaputt, jemand meldet es, es wird im nächsten Release behoben. Diese Sprache überlebt den Kontakt mit einer regulierten Branche nicht.
Wir haben MedLabel für einen nach ISO 13485 zertifizierten Medizinproduktehersteller in Deutschland gebaut. Das System erzeugt UDI-konforme CE-Etiketten, Lagerplatz-Etiketten und Einzelprodukt-Etiketten aus den Produktdaten des Unternehmens. In diesem Umfeld ist ein falsches Etikett kein Formatierungsproblem. Es ist eine Nichtkonformität — sie kann Korrekturmaßnahmen auslösen, Lieferungen verzögern und regulatorische Risiken schaffen. Die Kosten des Fehlers sind nicht die Behebung. Es ist alles, was der Fehler in Gang setzt.
Wenn man das akzeptiert, ändert sich die Aufgabenstellung. Man fragt nicht mehr: “Erzeugt es das richtige Etikett?” Man fragt: “Kann es überhaupt ein falsches erzeugen?”
Korrektheit durch Konstruktion, nicht durch Anweisung
Es gibt zwei Wege zu einem konformen Ergebnis. Man schreibt eine Arbeitsanweisung und vertraut darauf, dass Menschen sie befolgen. Oder man baut ein System, in dem die nicht konforme Variante gar nicht erst zur Verfügung steht.
MedLabel geht den zweiten Weg: Es erzwingt die erforderlichen Datenfelder je Etikettentyp. Genau die Auslassungen, die ein Etikett nicht konform machen würden, lassen sich also gar nicht speichern und drucken. Die mehrsprachige Ausgabe richtet sich nach dem Zielmarkt statt danach, dass eine Person die richtige Vorlage auswählt — das entfernt eine weitere Fehlerquelle. Die Korrektheit steckt in der Software, nicht im Gedächtnis eines Menschen an einem hektischen Produktionstag.
Das ist der Unterschied zwischen einem System, das Konformität erlaubt, und einem System, das sie erzeugt.
Rückverfolgbarkeit muss strukturell sein
Dieselbe Logik gilt für Aufzeichnungen. Auditoren fragen nicht, ob Sie grundsätzlich etwas dokumentieren. Sie fragen, was mit genau dieser Charge an genau diesem Tag passiert ist — und erwarten eine Antwort, die Sie zeigen können.
Deshalb ist in MedERP — einem mandantenfähigen ERP für eine Gruppe von Medizinprodukte- und Instrumentenherstellern — die Verfolgung von Charge, Los und Seriennummer in jede Transaktion eingebaut, statt als Auswertungsschicht obendrauf zu liegen. Die Etikettierung erfüllt dort sowohl EU-UDI- als auch FDA-Anforderungen, über mehrere Gesellschaften, Länder und Währungen hinweg.
Die allgemeine Regel: Nachträglich angebaute Rückverfolgbarkeit erfasst nur, woran jemand gedacht hat. In das Datenmodell eingebaute Rückverfolgbarkeit erfasst, was tatsächlich passiert ist — weil es keinen Weg durch das System gibt, der daran vorbeiführt.
Änderungskontrolle ist ein Engineering-Problem
Regulierte Software darf sich außerdem nicht beiläufig ändern. Jedes Release muss bewusst, dokumentiert und umkehrbar sein — eine echte Einschränkung, wenn das Geschäft trotzdem vorankommen muss.
MedERP hat das gelöst, indem es Modul für Modul gewachsen ist: Live gehen mit dem, was fertig war, während die Entwicklung am Rest weiterlief — ohne den bereits produktiven Betrieb zu stören. Das ist ebenso eine Liefer- wie eine Architekturdisziplin: getrennte Umgebungen, QA und Testing vor jedem Release und eine klare Aufzeichnung darüber, was sich geändert hat und warum.
Der Teil, den man mitnehmen sollte
Was wir aus dieser Arbeit in Projekte ganz ohne Regulierungsbehörde übernommen haben:
Erzwungene Korrektheit schlägt dokumentierte Korrektheit — jedes Mal, wenn Sie einen ungültigen Zustand unmöglich machen, entfernen Sie eine ganze Fehlerklasse dauerhaft. Strukturelle Rückverfolgbarkeit beantwortet Fragen, die noch niemand gestellt hat. Und kontrollierte, dokumentierte Änderungen sind der Grund, warum Sie auch im vierten Jahr noch souverän releasen können.
Der Punkt ist: Auditfähigkeit ist keine Last, die man gutem Engineering aufsetzt. Sie ist dessen strengere Definition. Teams, die für die Medizintechnik bauen, haben schlicht nicht die Möglichkeit, das später herauszufinden.
Wenn Sie etwas bauen, bei dem “es funktioniert” beweisbar sein muss: Das haben wir schon gemacht.