In kaum einer Branche entscheidet die architektonische Integrität von Software so direkt über physische Unversehrtheit wie im medizinischen Sektor. Ob eingebettete Firmware in Beatmungsgeräten oder eigenständige Diagnose-Pipelines als Software as a Medical Device (SaMD): Ein Ausfall, ein Race-Condition-Fehler oder eine unzureichend validierte Machine-Learning-Inferenz kann unmittelbare gesundheitliche Schäden nach sich ziehen. Die europäische Medical Device Regulation (MDR 2017/745) sowie internationale Normen wie die IEC 62304 und die ISO 14971 bilden den verbindlichen regulatorischen Rahmen, der Software-Engineering-Prozesse von der ersten Anforderung bis zur Post-Market Surveillance auditiert.

Die Weichenstellung: Zweckbestimmung und Risikoklassifizierung

Der regulatorische Lifecycle beginnt nicht beim Code, sondern bei der formalen Intended Purpose (Zweckbestimmung). Sobald eine Applikation zur Diagnose, Überwachung, Behandlung oder Linderung von Krankheiten dient, greift die MDR. Über die Klassifizierungsregeln – insbesondere Regel 11 des Anhangs VIII der MDR – werden viele ehemals unkritische Softwarelösungen schlagartig in höhere Risikoklassen (Klasse IIa, IIb oder gar III) gestuft, sobald sie therapeutische Entscheidungen steuern oder diagnostische Daten liefern, die zu tödlichen oder irreversiblen Verschlechterungen führen könnten. Parallel verlangt die IEC 62304 eine Zuordnung in Sicherheitsklassen:

• Klasse A: Keine Verletzung oder Schädigung der Gesundheit möglich.
• Klasse B: Keine schwere Verletzung möglich.
• Klasse C: Tod oder schwere Verletzung als mögliches Fehlerszenario.

Diese Einstufung determiniert den geforderten Nachweisgrad: Für Klasse C sind unter anderem vollständige Traceability-Matrizen, formale Verifikationen von Software-Einheiten (Unit Testing) und detaillierte Regressionsanalysen vor jedem Release zwingend vorgeschrieben.

Schnittstelle zur Architektur: Risikominimierung nach ISO 14971

Klassische funktionale Sicherheitskonzepte trennen kritische von unkritischen Komponenten. Nach ISO 14971 müssen Risiken primär durch inhärent sicheres Design mitigiert werden, bevor Schutzmaßnahmen in Software oder bloße Warnhinweise greifen. Architektonisch erzwingt dies saubere Entkopplungsmuster wie Fault Isolation, Sandbox-Umgebungen und Watchdog-Mechanismen. Ein Softwarefehler in einem unkritischen UI-Modul darf unter keinen Umständen den Kontrollfluss einer Steuerungslogik kompromittieren.

// Beispiel: Deterministisches Risikomanagement über Guard Rails
typedef struct {
    uint32_t target_infusion_rate_ml_h;
    uint32_t max_hardware_limit_ml_h;
    bool sensor_plausibility_ok;
} InfusionSafetyState;

SafetyStatus validate_and_apply_rate(const InfusionSafetyState *state) {
    if (!state->sensor_plausibility_ok) {
        // Fallback in sicheren Zustand nach ISO 14971
        halt_actuator_immediately();
        return STATUS_SAFETY_LOCKOUT;
    }
    if (state->target_infusion_rate_ml_h > state->max_hardware_limit_ml_h) {
        log_safety_violation(state->target_infusion_rate_ml_h);
        return STATUS_OUT_OF_BOUNDS;
    }
    execute_pumping_cycle(state->target_infusion_rate_ml_h);
    return STATUS_NOMINAL;
}

CI/CD und Traceability: Agile Praktiken im regulierten Umfeld

Ein weit verbreitetes Missverständnis ist die Annahme, Medizintechnik erfordere zwingend starre Wasserfall-Vorgehensmodelle. Moderne Entwicklungsorganisationen etablieren hochgradig automatisierte Toolchains, die regulatorische Anforderungen wie die Traceability (Rückverfolgbarkeit von Anforderung über Risikoanalyse, Testfall bis zum konkreten Git-Commit) in Continuous-Integration-Pipelines integrieren. Werkzeuge müssen im Rahmen des Qualitätsmanagementsystems (QMS nach ISO 13485) tool-validiert werden, um sicherzustellen, dass Compiler-Optimierungen, Static-Analysis-Linter (z.B. MISRA-Compliance) und Test-Frameworks verlässliche Ergebnisse liefern.

Herausforderung KI: Der Schritt von statischer Logik zu adaptiven Systemen

Besondere Komplexität entsteht bei KI-gestützten Medizinprodukten. Die MDR verlangt Reproduzierbarkeit, klinische Evidenz und kontrollierte Änderungsverfahren. Ein sich selbst im laufenden Betrieb aktualisierendes Modell widerspricht dem klassischen Konformitätsbewertungsverfahren, da jede Gewichtsänderung eine wesentliche Produktänderung darstellen kann. Architekturen in diesem Bereich setzen daher überwiegend auf Locked Models, bei denen der Modellzustand versioniert, deterministisch getestet und mit transparenten Konfidenzintervallen versehen wird, ergänzt durch umfassende Post-Market-Monitoring-Systeme zur Erkennung von Data Drifts.