TL;DR

• DSGVO Art. 9 stuft Gesundheitsdaten als besondere Kategorie ein -- Kubernetes-Cluster im Gesundheitswesen brauchen verstaerkte Schutzmassnahmen und dokumentierte Rechtsgrundlagen
• HL7 FHIR auf Kubernetes ermoeglicht interoperable Gesundheitsdaten-Services, die als Microservices skalieren und unabhaengig deployed werden koennen
• KRITIS-Anforderungen fuer Krankenhaeuser ab 30.000 vollstationaeren Faellen verlangen BSI-konforme IT-Sicherheit und Meldepflichten
• Namespace-Isolation trennt Patientendaten, klinische Systeme und Verwaltung auf Cluster-Ebene und erfuellt das Prinzip der Datensparsamkeit
• Hochverfuegbarkeit ist im Klinikbetrieb keine Option sondern Pflicht -- Pod-Disruption-Budgets und Multi-Zone-Deployments sichern den 24/7-Betrieb

Kubernetes im Gesundheitswesen: Container-Plattform fuer Kliniken und Krankenhaeuser

Das Gesundheitswesen befindet sich mitten in der digitalen Transformation. Elektronische Patientenakten, Telemedizin, KI-gestuetzte Diagnostik und vernetzte Medizingeraete erzeugen neue Anforderungen an die IT-Infrastruktur von Kliniken. Gleichzeitig gehoeren Gesundheitsdaten zu den am staerksten geschuetzten Datenkategorien der DSGVO.

Kubernetes bietet die Plattform, um diese Anforderungen zusammenzubringen: skalierbare Microservices fuer klinische Anwendungen, standardisierte Deployments und die technischen Werkzeuge fuer Datenschutz und Compliance. Dieser Guide zeigt, wie Krankenhaeuser und Kliniken Kubernetes DSGVO-konform und KRITIS-gerecht betreiben.

Regulatorischer Rahmen: Was Kliniken beachten muessen

DSGVO Art. 9: Besondere Kategorien personenbezogener Daten

Gesundheitsdaten fallen unter Art. 9 DSGVO und geniessen den hoechsten Schutzstatus. Die Verarbeitung ist grundsaetzlich verboten, es sei denn, eine der Ausnahmen nach Art. 9 Abs. 2 greift. Fuer Krankenhaeuser sind relevant:

• Art. 9 Abs. 2 lit. h: Verarbeitung fuer Zwecke der Gesundheitsversorgung
• Art. 9 Abs. 2 lit. i: Verarbeitung aus Gruenden des oeffentlichen Interesses im Bereich der oeffentlichen Gesundheit

Fuer Kubernetes bedeutet das: Jeder Namespace, der Patientendaten verarbeitet, muss dokumentierte technisch-organisatorische Massnahmen (TOMs) nach Art. 32 DSGVO vorweisen.

KRITIS: Kritische Infrastruktur Krankenhaus

Krankenhaeuser mit mindestens 30.000 vollstationaeren Faellen pro Jahr gelten als Kritische Infrastruktur (KRITIS). Die KRITIS-Verordnung verlangt:

Detaillierte BSI-Compliance-Strategien fuer Kubernetes finden Sie unter Kubernetes Compliance DSGVO und BSI.

Weitere relevante Vorschriften

Paragraph 203 StGB (Schweigepflicht): Aerzte, Pfleger und alle Mitarbeiter im Krankenhaus unterliegen der Schweigepflicht. Das betrifft auch IT-Dienstleister, die auf Patientendaten zugreifen koennten. Kubernetes RBAC muss sicherstellen, dass nur berechtigte Personen und Services auf Patientendaten-Namespaces zugreifen.

SGB V: Das Sozialgesetzbuch regelt die digitale Gesundheitsversorgung, einschliesslich der elektronischen Patientenakte (ePA) und der Telematikinfrastruktur.

DiGAV: Die Verordnung ueber digitale Gesundheitsanwendungen stellt Anforderungen an Datenschutz und Informationssicherheit fuer Apps auf Rezept.

HL7 FHIR auf Kubernetes: Interoperable Gesundheitsdaten-Services

Was ist HL7 FHIR?

HL7 FHIR (Fast Healthcare Interoperability Resources) ist der Standard fuer den Austausch von Gesundheitsdaten zwischen Systemen. FHIR nutzt eine REST-API mit JSON/XML-Ressourcen -- das passt ideal zu einer Microservice-Architektur auf Kubernetes.

FHIR Server als Kubernetes Deployment

Ein FHIR Server wie HAPI FHIR laesst sich als Deployment auf Kubernetes betreiben:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hapi-fhir-server
  namespace: clinical-systems
  labels:
    app: hapi-fhir
    data-classification: "patient-data"
    compliance: "dsgvo-art9"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hapi-fhir
  template:
    metadata:
      labels:
        app: hapi-fhir
        data-classification: "patient-data"
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 1000
      containers:
        - name: hapi-fhir
          image: registry.internal/hapi-fhir:7.2.0
          ports:
            - containerPort: 8080
          env:
            - name: SPRING_DATASOURCE_URL
              value: "jdbc:postgresql://postgres-fhir:5432/hapi_fhir"
            - name: SPRING_DATASOURCE_USERNAME
              valueFrom:
                secretRef:
                  name: fhir-db-credentials
                  key: username
            - name: HAPI_FHIR_TESTER_HOME_SERVER_ADDRESS
              value: "https://fhir.klinik-intern.de/fhir"
          resources:
            requests:
              cpu: "500m"
              memory: "2Gi"
            limits:
              cpu: "2"
              memory: "4Gi"
          livenessProbe:
            httpGet:
              path: /actuator/health
              port: 8080
            initialDelaySeconds: 60
            periodSeconds: 15
          readinessProbe:
            httpGet:
              path: /actuator/health
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
      volumes:
        - name: fhir-config
          configMap:
            name: hapi-fhir-config

Der FHIR Server laeuft mit 3 Replicas fuer Hochverfuegbarkeit, als Non-Root-User fuer Security und mit Resource Limits fuer Stabilitaet. Die Datenbank-Credentials kommen aus einem Kubernetes Secret, das idealerweise ueber einen External Secrets Operator aus einem Vault bezogen wird.

Microservice-Architektur fuer klinische Anwendungen

FHIR ermoeglicht eine saubere Trennung in Microservices, die jeweils eine FHIR-Ressource oder einen Use Case abdecken:

Klinische Microservices auf Kubernetes
├── Namespace: clinical-systems
│   ├── HAPI FHIR Server (zentrale FHIR API)
│   ├── Patient Service (FHIR Patient Resource)
│   ├── Encounter Service (Fallverwaltung)
│   ├── DiagnosticReport Service (Befunde)
│   └── MedicationRequest Service (Medikation)
├── Namespace: patient-portal
│   ├── Web Frontend (Patientenportal)
│   ├── Appointment Service (Terminvergabe)
│   └── Document Service (Arztbriefe)
├── Namespace: integration
│   ├── HL7v2 Adapter (Legacy-Systeme)
│   ├── DICOM Gateway (Bildgebung)
│   └── Lab Interface (Laboranbindung)
└── Namespace: platform
    ├── ArgoCD
    ├── Monitoring Stack
    └── Cert Manager

Jeder Service kann unabhaengig deployed, skaliert und aktualisiert werden. Das ist ein grosser Vorteil gegenueber monolithischen KIS-Systemen (Krankenhaus-Informationssystemen), die bei jedem Update komplett neu deployed werden muessen.

Patientendatenschutz auf Cluster-Ebene

Network Policies fuer Datentrennung

Patientendaten duerfen nur von autorisierten Services verarbeitet werden. Network Policies erzwingen diese Trennung auf Netzwerkebene:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: clinical-systems-isolation
  namespace: clinical-systems
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              access-clinical: "true"
        - podSelector:
            matchLabels:
              role: "clinical-service"
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres-fhir
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

Nur Namespaces mit dem Label access-clinical: true koennen den clinical-systems Namespace erreichen. Der Egress ist auf die FHIR-Datenbank und DNS beschraenkt. Jeder andere Traffic wird blockiert.

RBAC: Wer darf auf Patientendaten zugreifen?

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: clinical-developer
  namespace: clinical-systems
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: []

Entwickler koennen Deployments und Logs einsehen, haben aber keinen Zugriff auf Secrets. Deployments laufen ausschliesslich ueber GitOps. Direkter kubectl-Zugriff auf Pods mit Patientendaten (exec, port-forward) ist verboten. Weitergehende Security-Haertung beschreiben wir unter Kubernetes Security Hardening.

Datenverschluesselung

Encryption at Rest: etcd muss mit einem KMS-Provider verschluesselt werden. Patientendaten in Secrets oder ConfigMaps sind ohne Verschluesselung nur Base64-kodiert und damit im Klartext lesbar.

Encryption in Transit: Ein Service Mesh (z.B. Istio oder Linkerd) erzwingt mTLS zwischen allen Services. Das stellt sicher, dass Patientendaten auf dem Weg zwischen Microservices nicht abgefangen werden koennen.

Encryption at Application Level: Besonders sensible Daten (z.B. psychiatrische Diagnosen, HIV-Status) sollten zusaetzlich auf Anwendungsebene verschluesselt werden. Ein Envelope-Encryption-Pattern mit Vault stellt sicher, dass selbst bei einem Datenbank-Leak keine Klartextdaten exponiert werden.

Hochverfuegbarkeit im Klinikbetrieb

Pod-Disruption-Budgets fuer kritische Systeme

In einem Krankenhaus darf die IT nicht ausfallen. Pod-Disruption-Budgets (PDB) stellen sicher, dass bei Cluster-Wartung immer eine Mindestanzahl von Pods laeuft:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: fhir-server-pdb
  namespace: clinical-systems
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: hapi-fhir

Bei 3 Replicas und minAvailable 2 kann Kubernetes maximal 1 Pod gleichzeitig terminieren. Das gilt fuer Node-Drains bei Updates, nicht fuer ungeplante Ausfaelle. Fuer letztere sorgen die ReplicaSets automatisch fuer Ersatz.

Backup und Disaster Recovery

Patientendaten muessen regelmaessig gesichert werden. Ein Datenverlust ist im Krankenhausumfeld nicht nur ein IT-Problem, sondern kann Menschenleben gefaehrden. Velero sichert Kubernetes-Ressourcen und Persistent Volumes:

• Taegliche Backups aller clinical-systems Namespaces
• Verschluesselte Backup-Speicherung (AES-256)
• Regelmaessige Restore-Tests (mindestens quartalsweise)
• Dokumentierte Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO)

Details zu Backup-Strategien finden Sie unter Kubernetes Backup und Disaster Recovery.

Legacy-Integration: HL7v2 und DICOM

HL7v2 Adapter fuer Bestandssysteme

Viele Krankenhaus-Systeme kommunizieren noch ueber HL7v2, ein aelteres Nachrichtenformat. Ein Adapter-Service auf Kubernetes uebersetzt zwischen HL7v2 und FHIR:

HL7v2 Legacy-System
       |
       | (MLLP/TCP)
       v
HL7v2-to-FHIR Adapter (Kubernetes Pod)
       |
       | (REST/HTTPS)
       v
HAPI FHIR Server (Kubernetes Deployment)

Der Adapter laeuft als eigenstaendiger Service im integration-Namespace. Er nimmt HL7v2-Nachrichten per MLLP (Minimal Lower Layer Protocol) entgegen, transformiert sie in FHIR-Ressourcen und sendet sie an den FHIR Server. Das erlaubt eine schrittweise Migration von Legacy-Systemen, ohne bestehende Schnittstellen zu brechen.

DICOM Gateway fuer Bildgebung

Radiologische Bilder (CT, MRT, Roentgen) werden ueber das DICOM-Protokoll uebertragen. Ein DICOM Gateway auf Kubernetes nimmt Bilder von Modalitaeten entgegen, speichert sie im PACS (Picture Archiving and Communication System) und stellt Metadaten als FHIR ImagingStudy-Ressourcen bereit.

Monitoring und Incident Response

Klinik-spezifisches Monitoring

Standard-Kubernetes-Monitoring reicht fuer den Klinikbetrieb nicht aus. Zusaetzlich zu CPU, Memory und Pod-Status brauchen Sie:

• Antwortzeiten klinischer Systeme: FHIR Server Response Time muss unter 500ms liegen
• Verfuegbarkeit pro Service: 99.9% Uptime fuer patientenrelevante Systeme
• Datenintegritaet: Checksummen fuer FHIR-Ressourcen, um Datenkorruption zu erkennen
• Compliance-Metriken: Anzahl offener Policy-Violations, failed Audit Checks

Ein umfassender Monitoring-Stack wird unter Kubernetes Monitoring und Observability beschrieben.

Incident Response und 72-Stunden-Meldepflicht

Bei einem Datenschutzvorfall mit Patientendaten greift die 72-Stunden-Meldepflicht der DSGVO (Art. 33). Der Incident-Response-Prozess muss automatisiert unterstuetzt werden:

1. Detection: Falco erkennt ungewoehnliches Verhalten in clinical-systems Pods
2. Alert: PagerDuty oder OpsGenie benachrichtigt das On-Call-Team
3. Containment: Automatisierte Network Policy isoliert betroffene Pods
4. Analysis: Audit Logs und Falco-Events werden korreliert
5. Notification: Datenschutzbeauftragter wird informiert, BSI-Meldung bei KRITIS

Haeufige Fehler bei Healthcare-Kubernetes-Projekten

Patientendaten in Logs: Kubernetes-Logs landen oft in zentralen Log-Systemen ohne Zugriffskontrollen. Stellen Sie sicher, dass klinische Services keine Patientendaten in stdout/stderr schreiben. Nutzen Sie strukturiertes Logging mit Daten-Maskierung.

Shared Cluster mit Verwaltung: Klinische Systeme und Verwaltungs-IT (E-Mail, HR, Buchhaltung) gehoeren nicht auf denselben Cluster. Die unterschiedlichen Compliance-Anforderungen machen eine saubere Trennung notwendig.

Kein Netzwerk-Monitoring zwischen Namespaces: Ohne Monitoring wissen Sie nicht, ob Network Policies tatsaechlich greifen. Nutzen Sie ein Service Mesh mit Traffic-Metriken oder Cilium Hubble fuer Netzwerk-Observability.

Updates ohne Wartungsfenster: In Kliniken laufen kritische Systeme rund um die Uhr. Kubernetes-Updates muessen so geplant werden, dass die Patientenversorgung nicht beeintraechtigt wird. Nutzen Sie Rolling Updates mit PDBs und planen Sie Rollback-Szenarien.

Checkliste: Kubernetes fuer Krankenhaeuser

Fazit

Kubernetes bietet Krankenhaeusern und Kliniken eine moderne Plattform, um die steigende Komplexitaet klinischer IT-Systeme beherrschbar zu machen. Die Kombination aus Container-Isolation, deklarativer Konfiguration und Automatisierung passt gut zu den hohen Compliance-Anforderungen im Gesundheitswesen.

Der wichtigste Grundsatz: Patientendatenschutz ist keine nachtraegliche Ergaenzung, sondern muss von Anfang an in die Cluster-Architektur eingebaut werden. Network Policies, RBAC, Verschluesselung und Audit Logging sind keine optionalen Features, sondern Grundvoraussetzungen.

Wenn Sie Unterstuetzung bei der Planung Ihrer Kubernetes-Strategie im Gesundheitswesen brauchen, kontaktieren Sie uns unter /kontakt.