Medizinische Bilder
sind mehr als Dateien

Vom Untersuchungsauftrag bis zum Bildarchiv

In einem Spital entstehen Bilddaten nicht in einem einzigen System. Ein Krankenhausinformationssystem kann den Fall führen, ein Radiologieinformationssystem plant die Untersuchung, eine Modalität wie CT oder MR erzeugt Bilder, und ein PACS speichert und verteilt sie. Befundung, Forschung oder AI-Auswertung können weitere Systeme sein. Integration bedeutet deshalb nicht „eine Datei kopieren“, sondern einen medizinischen Fall über mehrere Verantwortungsgrenzen korrekt zu referenzieren.

Die Systeme haben unterschiedliche Aufgaben. Die Modalität kennt Aufnahmeparameter und erzeugt Instanzen. Das PACS sorgt für Speicherung und Abruf. Ein Auftragssystem kennt Indikation, Termin und organisatorischen Kontext. Diese Daten dürfen nicht beliebig gegenseitig überschrieben werden. Gerade weil mehrere Systeme denselben Patienten oder dieselbe Untersuchung beschreiben, braucht es eindeutige Verantwortungen und Identitäten.

Patient → Study → Series → Instance

Orthanc ordnet DICOM-Ressourcen in vier Ebenen. Ein Patient kann mehrere Studien haben. Eine Studie steht für einen Untersuchungszusammenhang. Sie enthält eine oder mehrere Serien, etwa verschiedene Rekonstruktionen oder Sequenzen. Eine Serie enthält einzelne Instanzen – häufig Bildschnitte, aber DICOM kann auch andere medizinische Objekte repräsentieren.

Drei IDs, drei verschiedene Fragen

Im Async-Labor begegnen sich mindestens drei Identitäten. Die eventId beantwortet: „Ist genau diese Meldung schon verarbeitet worden?“ Die StudyInstanceUID beantwortet: „Von welcher medizinischen Studie sprechen die Systeme?“ Die Orthanc Study ID beantwortet: „Unter welchem lokalen Schlüssel finde ich die Studie in dieser konkreten Orthanc-Instanz?“ Zusätzlich verbindet eine Correlation-ID alle technischen Schritte eines Verarbeitungslaufs.

Diese IDs dürfen nicht vermischt werden. Eine Wiederholung desselben Events soll keine zweite Wirkung auslösen. Zwei unterschiedliche Events können aber dieselbe Studie betreffen, etwa „Studie verfügbar“ und später „Befund freigegeben“. Die lokale Orthanc-ID kann sich beim Transfer in eine andere Orthanc-Instanz ändern; die fachliche DICOM-UID bleibt der systemübergreifende Bezug.

{
  "id": "evt-study-0042",
  "type": "ch.teko.radiology.study.available.v1",
  "correlationId": "corr-imaging-0042",
  "data": {
    "orthancStudyId": "lokal-clinical-7ab3",
    "studyInstanceUid": "1.2.826.0.1.3680043.10.543.42",
    "accessionNumber": "DEMO-0042",
    "modality": "CT"
  }
}

Was Orthanc im Labor leistet

Orthanc ist ein leichtgewichtiges, quelloffenes DICOM-System. Es kann DICOM-Ressourcen speichern, hierarchisch zugänglich machen und über eine REST-API steuern. Damit wird ein PACS-ähnlicher Integrationspunkt lokal per Docker reproduzierbar. Die eingebaute Oberfläche selbst verwendet die REST-API – ein gutes Beispiel dafür, wie ein Webclient auf einem API-Vertrag aufsetzt.

Für das Labor läuft Orthanc nur im privaten Compose-Netz. Die öffentliche Website gibt weder den DICOM-Port noch die Adminoberfläche frei. Die Lern-API ruft intern ausgewählte Orthanc-Endpunkte auf und gibt nur minimierte, synthetische Informationen zurück. Das reduziert Angriffsfläche und verhindert, dass Lernende versehentlich administrative Operationen gegen das PACS ausführen.

Die offizielle Orthanc REST-Dokumentation beschreibt diese Routen und die Hierarchie. Für produktive Systeme braucht es zusätzlich belastbare Authentisierung, Autorisierung, Audit, Backup, Aufbewahrung, Netzwerksegmentierung und eine institutionelle Datenschutz- und Sicherheitsprüfung.

„Eingetroffen“ ist nicht automatisch „vollständig“

Eine CT-Studie kann aus vielen Instanzen bestehen. Beim ersten Bild weiß ein Integrator nicht sicher, ob noch weitere folgen. Orthanc protokolliert neue Ressourcen in einem Changes-Log und kennt einen stabilen Zustand, nachdem eine gewisse Zeit keine neue Instanz eingetroffen ist. Dieser Zustand ist eine praktische Annäherung, aber kein mathematischer Beweis für Vollständigkeit. Unterbrochene Übertragungen oder verspätete Serien bleiben möglich.

Ein Eventpublisher sollte deshalb nicht für jedes Bild sofort eine vollständige Studienverarbeitung starten. Typisch ist, auf ein stabiles Studienereignis zu reagieren, die erwarteten Pflichtinformationen zu prüfen und dann nur eine kleine Nachricht mit Referenzen in die Queue zu legen. Große Bilddaten bleiben im PACS und werden vom autorisierten Worker bei Bedarf geholt. So bleibt die Message klein, und Zugriffe auf die eigentlichen Daten können separat kontrolliert und protokolliert werden.

Die Verarbeitung sollte mindestens den Eventvertrag validieren, die Studie intern abrufen, den erlaubten Zweck prüfen, eine geeignete Anonymisierung oder Pseudonymisierung ausführen, das Ziel idempotent ansprechen und einen Transfernachweis speichern. Ein technischer Timeout wird mit Backoff erneut versucht. Ein fehlender fachlicher Pflichtwert landet nicht in einer Endlosschleife, sondern in einer kontrollierten Quarantäne.

Gesundheitsdaten erzwingen Datenminimierung

Im öffentlichen TEKO-Labor werden ausschließlich erfundene IDs und synthetische Metadaten verwendet. Der Endpunkt akzeptiert keine DICOM-Dateien und keine frei eingegebenen Patientennamen. Das ist nicht nur eine technische Einschränkung, sondern eine didaktische Aussage: Ein Demo-System im Internet ist kein Ort für echte Gesundheitsdaten.

Anonymisierung ist mehr als das Ersetzen eines sichtbaren Namens. Identifizierende Informationen können in zahlreichen DICOM-Tags, privaten Hersteller-Tags, eingebrannten Pixeltexten oder verknüpften Systemen vorkommen. Eine reale Sekundärnutzung braucht deshalb ein geprüftes Profil, Zweckbindung, Zugriffsregeln und eine Kontrolle des Ergebnisses. „Wir haben PatientName gelöscht“ ist kein ausreichender Nachweis.

Entscheidungsregeln und Kontrollfragen

• Events klein halten: eine Referenz und notwendige Metadaten transportieren, Bilddaten kontrolliert am Ursprung abrufen.
• Fachliche und lokale IDs trennen: lokale Orthanc-IDs nicht als universelle Studienidentität behandeln.
• Stabilität als Signal, nicht als Beweis verstehen: bei kritischen Workflows zusätzlich Vollständigkeitsregeln oder Auftragsabgleich verwenden.
• Idempotent übertragen: vor einer Zielwirkung die Kombination aus fachlichem Schlüssel und Prozessversion prüfen.
• Fehler klassifizieren: Netzwerk-/Dienstfehler wiederholen; ungültige Metadaten isolieren und fachlich klären.
• Öffentliche Demos begrenzen: keine Adminoberflächen, DICOM-Ports, Uploads oder echten Identitäten exponieren.