TL;DR

• Software as Medical Device (SaMD) unterliegt der EU-Medizinprodukteverordnung (MDR) -- das betrifft auch die Infrastruktur, auf der die Software laeuft
• Audit-Trail und Rueckverfolgbarkeit sind MDR-Pflicht: Jede Aenderung an der Produktionsumgebung muss dokumentiert, genehmigt und nachvollziehbar sein
• IQ/OQ/PQ-Validierung (Installationsqualifizierung, Operationsqualifizierung, Leistungsqualifizierung) laesst sich mit GitOps und automatisierten Tests auf Kubernetes abbilden
• Regulatorik-Teams sollten keine Kubernetes-Cluster verwalten -- ein Managed Service mit eingebauter Compliance-Dokumentation trennt Verantwortlichkeiten sauber
• Kosten: Managed Kubernetes mit MDR-Dokumentation ab 4.500 EUR/Monat vs. internes Team ab 500.000 EUR/Jahr

Kubernetes fuer Medizintechnik: MDR-Compliance fuer Software as Medical Device

Medizintechnik-Unternehmen, die Software as Medical Device (SaMD) entwickeln, stehen vor einem doppelten Problem: Die Software muss medizinische Anforderungen erfuellen, und die Infrastruktur, auf der sie laeuft, muss ebenfalls regulatorisch konform sein. Die MDR (Medical Device Regulation, EU 2017/745) macht keinen Unterschied zwischen dem Algorithmus und der Plattform, auf der er laeuft.

Kubernetes kann die technische Basis fuer SaMD-Produkte liefern. Aber der Betrieb einer Kubernetes-Plattform, die einer Benannten Stelle (Notified Body) standhaelt, erfordert Expertise, die weit ueber normales DevOps hinausgeht.

Was die MDR fuer Software-Infrastruktur bedeutet

SaMD-Klassifizierung und ihre Konsequenzen

Die MDR klassifiziert Medizinprodukte in Risikoklassen. Fuer SaMD gelten die Regeln 9 bis 11 aus Anhang VIII:

Ab Klasse IIa muss die gesamte Software-Lieferkette dokumentiert sein. Das schliesst die Container-Infrastruktur explizit ein. Eine Benannte Stelle wird bei einem Audit fragen: Wer hat wann welche Aenderung an der Produktionsumgebung vorgenommen? Wie stellen Sie sicher, dass die validierte Software-Version identisch mit der deployen Version ist?

GSPR: Grundlegende Sicherheits- und Leistungsanforderungen

Anhang I der MDR definiert die General Safety and Performance Requirements (GSPR). Fuer SaMD auf Kubernetes sind insbesondere relevant:

• GSPR 14.2 (d): Wiederholbarkeit, Zuverlaessigkeit und Leistung der Software
• GSPR 17.1: Cybersicherheit der Software und ihrer Umgebung
• GSPR 17.2: Schutz vor unberechtigtem Zugriff
• GSPR 23.4: Massnahmen gegen Manipulation und Faelschung

Das bedeutet: Die Kubernetes-Infrastruktur muss nachweisbar sicher, wiederholbar deploybar und gegen Manipulation geschuetzt sein.

Audit-Trail: Jede Aenderung dokumentiert

Warum Git allein nicht reicht

Viele Entwickler-Teams denken: Wir nutzen Git, also haben wir einen Audit-Trail. Das stimmt fuer den Quellcode. Aber die MDR verlangt Rueckverfolgbarkeit auf mehreren Ebenen:

1. Quellcode: Wer hat wann welche Aenderung am Code gemacht? (Git)
2. Build-Artefakte: Welcher Code wurde zu welchem Container-Image gebaut? (CI/CD)
3. Deployment: Welches Image laeuft wann in Produktion? (Kubernetes + GitOps)
4. Infrastruktur: Welche Cluster-Konfiguration war zum Zeitpunkt X aktiv? (IaC + Audit-Log)
5. Betrieb: Welche Incidents gab es und wie wurden sie behoben? (ITSM)

GitOps als MDR-konformes Deployment

GitOps mit ArgoCD oder Flux erzwingt, dass jede Aenderung an der Produktionsumgebung durch einen Git-Commit dokumentiert ist. Kein manuelles kubectl apply, kein SSH auf Worker-Nodes.

# argocd-application-samd.yaml
# MDR-konformes Deployment: Nur genehmigte Aenderungen werden deployed
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: diagnostic-engine-production
  namespace: argocd
  annotations:
    mdr.compliance/classification: "IIb"
    mdr.compliance/udi-di: "DE-MF-000123456-00"
    mdr.compliance/software-version: "2.4.1"
spec:
  project: samd-production
  source:
    repoURL: https://git.medtech-intern.de/platform/samd-manifests.git
    targetRevision: release/2.4.1
    path: production/diagnostic-engine
  destination:
    server: https://kubernetes.default.svc
    namespace: samd-production
  syncPolicy:
    automated:
      prune: false
      selfHeal: true
    syncOptions:
    - CreateNamespace=false
    - Validate=true
    - PruneLast=true

Wichtige Details:

• targetRevision: release/2.4.1 -- Kein main Branch, sondern ein getaggter Release. Die Benannte Stelle will wissen, welche exakte Version in Produktion laeuft.
• prune: false -- Ressourcen werden nie automatisch geloescht. Jede Entfernung muss bewusst erfolgen.
• Annotations dokumentieren MDR-Klassifizierung und UDI-DI (Unique Device Identification) direkt am Kubernetes-Objekt.

Kubernetes Audit-Log fuer MDR

# audit-policy-mdr.yaml
# Umfassende Protokollierung fuer MDR-konforme Infrastruktur
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Alle Aenderungen an SaMD-Namespaces vollstaendig protokollieren
- level: RequestResponse
  namespaces: ["samd-production", "samd-staging"]
  verbs: ["create", "update", "patch", "delete"]
  resources:
  - group: "apps"
    resources: ["deployments", "statefulsets", "daemonsets"]
  - group: ""
    resources: ["configmaps", "secrets", "services"]
  - group: "networking.k8s.io"
    resources: ["networkpolicies", "ingresses"]
# Lesezugriffe auf sensible Ressourcen protokollieren
- level: Metadata
  namespaces: ["samd-production"]
  resources:
  - group: ""
    resources: ["secrets"]
  verbs: ["get", "list", "watch"]
# Zugriffe auf Patientendaten-Services
- level: Request
  namespaces: ["samd-production"]
  resources:
  - group: ""
    resources: ["pods/exec", "pods/attach"]
  verbs: ["create"]
# Alles andere: Metadata-Level
- level: Metadata

Diese Audit-Policy stellt sicher, dass die Benannte Stelle bei einem Audit jede Aenderung an der Produktionsumgebung nachvollziehen kann. Die Logs muessen mindestens 10 Jahre aufbewahrt werden (MDR Artikel 10, Absatz 8).

IQ/OQ/PQ: Validierung auf Kubernetes

Was IQ/OQ/PQ bedeutet

Die Validierung medizintechnischer Software folgt dem V-Modell und umfasst drei Qualifizierungsstufen:

IQ: Installationsqualifizierung automatisieren

Die IQ prueft, ob die Infrastruktur korrekt aufgesetzt ist. Auf Kubernetes laesst sich das mit automatisierten Tests abbilden:

# iq-validation-job.yaml
# Automatisierte Installationsqualifizierung
apiVersion: batch/v1
kind: Job
metadata:
  name: iq-validation-2-4-1
  namespace: samd-validation
  labels:
    validation-type: iq
    software-version: "2.4.1"
    mdr-class: "IIb"
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      serviceAccountName: validation-runner
      containers:
      - name: iq-tests
        image: registry.medtech-intern.de/validation-suite:1.8.0
        command: ["python", "-m", "pytest"]
        args:
        - "tests/iq/"
        - "--junitxml=/results/iq-report.xml"
        - "-v"
        env:
        - name: TARGET_NAMESPACE
          value: "samd-production"
        - name: EXPECTED_K8S_VERSION
          value: "1.30"
        - name: EXPECTED_NODES
          value: "3"
        - name: EXPECTED_STORAGE_CLASS
          value: "encrypted-ssd"
        volumeMounts:
        - name: results
          mountPath: /results
      volumes:
      - name: results
        persistentVolumeClaim:
          claimName: validation-results-pvc

Was die IQ-Tests pruefen:

• Kubernetes-Version entspricht der Spezifikation
• Anzahl und Konfiguration der Worker-Nodes
• Network Policies sind aktiv und korrekt
• Storage-Klasse mit Verschluesselung ist verfuegbar
• RBAC-Rollen sind wie dokumentiert konfiguriert
• Monitoring und Alerting sind funktionsfaehig

OQ: Operationsqualifizierung

Die OQ prueft, ob das System unter definierten Bedingungen korrekt funktioniert. Das umfasst Failover-Tests, Health-Check-Validierung und Backup-Recovery. Die Tests laufen als Kubernetes Jobs im Validation-Namespace -- analog zur IQ, aber mit Fokus auf operatives Verhalten (Pod-Restart nach Crash, Failover zwischen Availability Zones, automatisches Recovery nach Node-Ausfall).

PQ: Leistungsqualifizierung

Die PQ simuliert Produktionsbedingungen und misst, ob die Leistungsanforderungen erfuellt werden:

PQ-Testprotokoll fuer SaMD Diagnostic Engine v2.4.1
====================================================

Testbedingung                    Anforderung       Ergebnis        Status
-------------------------------------------------------------------
Antwortzeit (P95)               unter 200ms        142ms           BESTANDEN
Antwortzeit (P99)               unter 500ms        287ms           BESTANDEN
Durchsatz                       500 Req/s          623 Req/s       BESTANDEN
Verfuegbarkeit (72h-Test)       99,9%              99,97%          BESTANDEN
Failover-Zeit                   unter 30s          12s             BESTANDEN
Backup-Recovery                 unter 4h           2h 15min        BESTANDEN
Datenkonsistenz nach Failover   100%               100%            BESTANDEN

Diese Protokolle muessen in der Technischen Dokumentation (MDR Anhang II) hinterlegt und bei jedem Release aktualisiert werden.

Cybersecurity: GSPR 17 auf Kubernetes

Die MDR verlangt Cybersicherheit nicht nur als Empfehlung, sondern als Grundlegende Anforderung. GSPR 17 betrifft direkt die Kubernetes-Infrastruktur.

Network Policies fuer SaMD-Isolation

# network-policy-samd.yaml
# Strenge Netzwerkisolation fuer SaMD in Produktion
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: samd-strict-isolation
  namespace: samd-production
spec:
  podSelector:
    matchLabels:
      app: diagnostic-engine
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway
    ports:
    - protocol: TCP
      port: 8080
  egress:
  # Zugriff auf eigene Datenbank
  - to:
    - podSelector:
        matchLabels:
          app: diagnostic-db
    ports:
    - protocol: TCP
      port: 5432
  # DNS-Aufloesung
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

Container-Image-Sicherheit

Fuer SaMD muessen Container-Images signiert und auf bekannte Schwachstellen geprueft werden. Das laesst sich mit Validating Admission Policies umsetzen: Eine Policy prueft, ob alle Images aus der internen Registry stammen und ob sie signiert sind. Images aus externen Registries oder ohne Signatur werden abgelehnt. In Kombination mit CVE-Scanning in der CI/CD-Pipeline stellt das sicher, dass nur gepruefter und freigegebener Code in der Produktion laeuft.

Warum das Regulatorik-Team keine Kubernetes-Cluster verwalten sollte

In vielen Medizintechnik-Unternehmen mit 200 bis 500 Mitarbeitern gibt es ein QM-Team (Qualitaetsmanagement) und eine kleine IT-Abteilung. Die Realitaet sieht dann so aus:

• QM-Team: Kennt MDR, GSPR, Technische Dokumentation. Hat keine Kubernetes-Erfahrung.
• IT-Team: Kann Server administrieren. Hat keine MDR-Erfahrung und keine Container-Kompetenz.
• Entwickler: Koennen Software bauen. Haben weder Zeit noch Wissen fuer Infrastruktur-Betrieb.

Das Ergebnis: Entweder das QM-Team versucht Kubernetes zu verstehen (ineffizient) oder die IT ignoriert MDR-Anforderungen (gefaehrlich, weil das Audit scheitert).

Ein Managed-Service-Partner loest diese Trennung auf: Er betreibt die Kubernetes-Infrastruktur und liefert die Compliance-Dokumentation, die das QM-Team fuer die Technische Dokumentation braucht. Die Entwickler deployen ihre Software ueber CI/CD, ohne sich um Cluster-Management kuemmern zu muessen.

Wie Mittelstandsunternehmen mit begrenztem IT-Team trotzdem eine professionelle Kubernetes-Plattform betreiben, erklaeren wir in Kubernetes Skill-Gap im Mittelstand.

Kostenvergleich: Internes Team vs. Managed Service

Szenario: Medizintechnik-Unternehmen mit Klasse-IIb-SaMD

Option A: Internes Kubernetes-Team aufbauen

Plus Risiken: Personalfluktuation (Nachbesetzung dauert 6+ Monate), Wissensverlust, Audit-Findings wegen Dokumentationsluecken.

Option B: Managed Kubernetes mit MDR-Compliance

Die Ersparnis: 256.000 bis 383.000 EUR pro Jahr. Und die Compliance-Dokumentation ist Bestandteil des Service, nicht ein nachgelagerter Aufwand.

Fuer eine detaillierte Aufschluesselung der Leistungen lesen Sie Was 4.000 EUR/Monat Managed Kubernetes beinhaltet.

Post-Market Surveillance auf Kubernetes

Die MDR verlangt in Artikel 83 eine kontinuierliche Post-Market Surveillance. Fuer SaMD bedeutet das: Die Performance der Software muss nach dem Go-Live kontinuierlich ueberwacht werden. Kubernetes-Monitoring mit Prometheus liefert die Daten dafuer.

Konkret werden PrometheusRules definiert, die bei Ueberschreitung der validierten Grenzwerte (P95-Latenz ueber 200ms, Fehlerrate ueber 0,1%) automatisch Alerts ausloesen. Diese Alerts sind mit dem Label compliance: mdr versehen und fliessen direkt in den Post-Market Surveillance Report ein. Bei kritischen Abweichungen wird automatisch ein CAPA-Prozess (Corrective and Preventive Action) angestossen.

Technische Dokumentation: Was die Benannte Stelle sehen will

Bei einem Audit prueft die Benannte Stelle die Technische Dokumentation (MDR Anhang II). Fuer die Kubernetes-Infrastruktur muss diese enthalten:

Ein Managed-Service-Partner kann den Grossteil dieser Dokumentation automatisch generieren und pflegen. Das spart dem QM-Team hunderte Stunden pro Jahr.

Fuer weitere Informationen zu Compliance-Automatisierung empfehlen wir Kubernetes Compliance Automation.

Checkliste: Ist Ihr Medizintechnik-Unternehmen bereit fuer Kubernetes?

• Sie entwickeln Software, die unter die MDR faellt (SaMD Klasse I oder hoeher)
• Die aktuelle Infrastruktur ist manuell verwaltet und schlecht dokumentiert
• Audit-Findings beziehen sich regelmaessig auf IT-Dokumentation
• IQ/OQ/PQ-Validierungen sind manuell und dauern Wochen
• Das QM-Team und die IT-Abteilung sprechen verschiedene Sprachen
• Neue Software-Releases dauern Monate wegen Validierungsaufwand

Drei oder mehr Haken? Dann kann Managed Kubernetes mit eingebauter MDR-Compliance Ihre Time-to-Market verkuerzen und gleichzeitig die Audit-Sicherheit erhoehen.

Verwandte Artikel

• Kubernetes Compliance Automation -- Compliance-Anforderungen automatisch durchsetzen
• Was 4.000 EUR/Monat Managed Kubernetes beinhaltet -- Detaillierte Kostenaufschluesselung
• Kubernetes Skill-Gap im Mittelstand -- Das Personal-Problem loesen
• Kubernetes Security Hardening -- Sicherheits-Best-Practices fuer Container
• Cloud, DSGVO und Kubernetes-Compliance -- Datenschutz auf Container-Plattformen

Sie entwickeln Software as Medical Device und brauchen eine MDR-konforme Kubernetes-Infrastruktur? Wir betreiben Ihre Container-Plattform und liefern die Compliance-Dokumentation fuer die Technische Dokumentation mit. Jetzt Beratungsgespraech vereinbaren.