TEKO Schweizerische FachschuleEAI IntegrationslaborFallstudie · Spital Sonnenblick
LektionFall testen

Fallstudie · vollständig synthetisch

Spital Sonnenblick:
Bildstudien sicher weiterleiten

Eine radiologische Studie wird im klinischen Orthanc registriert. Ein Event startet die kontrollierte, idempotente Verarbeitung für ein Forschungsarchiv. Das Ziel darf ausfallen, ohne dass der Fall verloren geht oder doppelt entsteht.

OrthancDICOMEventRetryDLQIdempotenz
Szenario

Auftrag und Sicherheitsgrenze

Fachliches Ziel

Eine freigegebene Bildstudie soll für einen erlaubten Sekundärzweck vorbereitet werden. Der Status muss nachvollziehbar sein; technische Ausfälle dürfen nicht zu Verlust führen.

Grenze der Demo

Die öffentliche API akzeptiert nur synthetische DICOM-Metadaten. Keine Patientennamen, Geburtstage, Dateien oder echten UIDs eingeben. Der interne Orthanc-Dienst ist nicht direkt öffentlich.

Architektur

Eine kleine Nachricht, ein kontrollierter Datenzugriff

Asynchroner Orthanc-Spital-DatenflussEine synthetische Modalität sendet eine Studie an Clinical Orthanc. Ein Event gelangt über Queue und Worker zum Forschungsziel. Fehler führen über Retry in eine DLQ; Correlation-ID begleitet alle Schritte.SynthetischeCT/MR-StudieQueueWorkerForschungs-archivClinicalOrthancRetry / Backoffdanach DLQcorrelationId: corr-imaging-0042
Das Event transportiert Referenzen und minimierte Metadaten, nicht die Bildserie. Der Worker holt Daten intern und protokolliert nur technische Identitäten.
Rollen

Wer ist wofür verantwortlich?

Clinical Orthanc

Interne Quelle und technischer Speicher synthetischer Studien im Labor.

Event/API

Validiert Vertrag, vergibt Job- und Correlation-ID und dedupliziert.

Worker

Prüft Orthanc, klassifiziert Fehler und steuert Retry/DLQ.

Forschungsziel

Erhält nur für den Zweck vorbereitete, idempotent referenzierte Daten.

Eventvertrag

Keine Personendaten in der Queue

{
  "id": "evt-study-0042",
  "type": "ch.teko.radiology.study.available.v1",
  "source": "orthanc-clinical",
  "time": "2026-09-12T10:30:00Z",
  "correlationId": "corr-imaging-0042",
  "data": {
    "studyInstanceUid": "1.2.826.0.1.3680043.10.543.42",
    "accessionNumber": "DEMO-0042",
    "modality": "CT",
    "instanceCount": 12
  }
}
Warum fehlen PatientName und PixelData? Der Consumer braucht diese Werte nicht für Routing, Retry oder Deduplikation. Weniger Daten bedeuten weniger Kopien in Queue, Logs und DLQ und eine kleinere Schutzfläche.
Fehlerkatalog

Nicht jeder Fehler verdient einen Retry

FehlerKlasseReaktion
Orthanc kurz nicht erreichbartechnisch, wahrscheinlich temporärbegrenzter Retry mit Backoff
Timeout nach möglicher Wirkungtechnisch, Ausgang ungewissZielzustand/idempotenten Schlüssel prüfen
StudyInstanceUID fehltVertrags-/Fachfehlersofort ablehnen oder DLQ, kein Endlos-Retry
Modalität nicht erlaubtfachliche PolicyQuarantäne und bewusste Klärung
Event wird doppelt gesendeterwartetes Delivery-Verhaltenbestehenden Job zurückgeben, keine Doppelwirkung
Abnahme

Wann ist der Fall gelöst?

  1. Happy PathGültiger synthetischer CT-Fall endet in completed und besitzt Job- sowie Correlation-ID.
  2. VertragUnzulässige Felder und Modalitäten werden mit erklärbarem 4xx-Fehler abgewiesen.
  3. RetryEin temporärer Orthanc-Fehler erhöht Versuchszähler und erreicht danach entweder Recovery oder DLQ.
  4. IdempotenzGleicher Idempotency-Key erzeugt genau einen Job und eine fachliche Wirkung.
  5. DatenschutzKeine echten oder frei eingegebenen Patientendaten erscheinen in Request, Response oder Log.
  6. BetriebHealthchecks, Logs, Limits und Reset sind dokumentiert und getestet.
▶
Fall jetzt ausführen
Das Live-Labor erzeugt den synthetischen Job direkt gegen die öffentlich bereitgestellte API. Für die lokale Variante folgt dieselbe Route über http://localhost:3190.