Engineering zu spät: verifikationsgetriebene Entwicklung in der Medizintechnik

Von Filip Jaromczyk, Gründer von Techkrates 12. Januar 2026

Späte Anforderungen, späte Cybersecurity und späte Testbarkeit machen aus guter Arbeit teures Rework. In regulierter Medizintechnik eskaliert das schnell: Scope wächst, Evidence verschiebt sich, submission-driven Evidence wird zum Nachtragsprojekt.

Das späte Trio, das den Scope sprengt

Späte Anforderungen: Akzeptanzkriterien kommen, wenn Designentscheidungen bereits fix sind.
Späte Cybersecurity: Threat Model und Testplan tauchen erst nach Interface-Freeze auf.
Späte Testbarkeit: Kein Prüfstand früh genug, Nachweise kommen erst nach Hardware-Änderungen.

Dann wird Ursachenanalyse zum Feuerwehreinsatz und Retrofit ersetzt geplantes Fertigungsengineering.

Muster aus echten Projekten (NDA-safe)

Cover-Staining-Linie (anonymisiert): EOL-Wechsel + Feldprobleme + Evidence-Updates

In einer anonymisierten Cover-Staining-Linie führte ein EOL-Wechsel des Hauptrechners zu Feldproblemen und machte ein gezieltes Retrofit nötig. Die Lösung war mehr als ein Designfix: Verifikationsmethoden, Testkriterien und Evidence/Pflichtnachweise mussten aktualisiert werden.

Vernetztes System: kleine Embedded-Änderungen, grosse Aenderungsfolgen

In vernetzten Systemen reichen kleine Embedded-Änderungen, um eine grosse Validierungswelle auszulösen. CSV (Computer System Validation) weitet sich über Interfaces, Datenflüsse und Testnachweise aus. Ohne frühe Boundary-Definitionen wird jedes Firmware-Update zum Volltest.

Labore und Tests: warum Prüfstände früh helfen

Externe Labore sind langsam und teuer. Ein interner Prüfstand bringt Risiken früh ans Licht, unterstützt Ursachenanalyse und liefert Nachweise, solange das Design noch beweglich ist.

Dasselbe gilt für Langläufer-Tests, Aging und Stabilitätsnachweise: Sie dauern Monate und reagieren empfindlich auf Designänderungen. Wer sie startet, bevor Design und Testmethoden stabil sind, muss sie oft wiederholen.

Was besser funktioniert

Vom Ende her denken: Welche Nachweise brauchen wir für Release oder Submission?
Systemgrenzen früh definieren, damit Anforderungen und Tests denselben Scope haben.
Akzeptanzkriterien vor der Umsetzung definieren, um späten Rework zu vermeiden.
Cybersecurity-Evidence als Teil des Engineering-Workflows planen.
Prüfstand und Testmethodik früh aufbauen, damit Repeatability stimmt.
Aenderungsfolgen mit Change-Impact-Regeln begrenzen.
Evidence/Pflichtnachweise eng an das verifizierte System koppeln.