Wir haben unser eigenes Feature nach fünf Tagen wieder ausgebaut

Am 20. August 2026 haben wir Linumed Base auf v1.0.0 getaggt - mit Orthanc als siebter Rolle, einem DICOM-Server für die Bildarchivierung. Fünf Tage später war Orthanc komplett wieder raus, samt Major-Version-Bump auf v2.0.0. Nicht deprecated, nicht hinter einem Flag versteckt - entfernt. Der ehrliche Teil dieser Geschichte ist nicht die Entfernung. Es ist, dass die Aufnahme selbst der Fehler war.

Wie Orthanc überhaupt reinkam

Orthanc stand in der Architekturskizze von Linumed Base als letzter noch fehlender Dienst - der Punkt, an dem eine Liste einfach abgearbeitet wird, statt dass jemand fragt, ob der nächste Eintrag noch zur Produktgrenze passt. Base beschreibt sich selbst, seit vor Orthancs Aufnahme, mit einem klaren Satz: "No application software. No HIS, no DMS, no document management. Institutions bring their own applications; this provides the base they run on." Ein DICOM-Archiv mit eigener Datenbank, das Patientendaten unbegrenzt vorhält, ist Anwendungssoftware nach genau dieser Definition - keine Grauzone, sondern exakt das, was der Satz ausschließen sollte. Diese Prüfung fand zum Zeitpunkt der Aufnahme nicht statt. Momentum aus einer bereits gezeichneten Architektur, keine bewusste Abwägung gegen die eigene Grenze.

Was wir tatsächlich gemessen haben

Drei Befunde, alle aus derselben Woche, während zweier anderer, eigentlich unabhängiger Themen (eine DSGVO/KRITIS-Frage zu Zugriffsprotokollen und eine Scope-Frage, die daraus folgte):

1. Keine Zugriffsidentität in Orthancs eigenen Logs, bei keiner Verbosity-Stufe. Getestet gegen eine echte Instanz: Standard-Logging protokolliert pro Anfrage nichts, --verbose protokolliert Methode, Pfad und Timing - nie einen Benutzernamen, unabhängig davon, ob die Anfrage echte Zugangsdaten trug, falsche, oder keine:

I0823 05:28:40.037495 HTTP-1 ElapsedTimer.cpp:102] (http) GET /patients

Sitzt ein RIS mit einem einzigen geteilten REST-Account vor Orthanc - ein normales Integrationsmuster, und das einzige, das die entfernte Rolle überhaupt unterstützte -, erreicht die Identität der Person, die einen Befund tatsächlich angesehen hat, Orthanc nie. Kein Log-Shipping der Welt holt eine Identität zurück, die nie protokolliert wurde.

2. Echte, unbegrenzte Persistenz. StorageDirectory und IndexDirectory zeigten auf ein dediziertes Docker-Volume. Keine automatische Weiterleitung, keine automatische Löschung, kein S3-Offload standardmäßig aktiv (das Plugin liegt im Image, aber nichts in diesem Setup schaltete es ein). Die README der entfernten Rolle nannte es selbst "ein Archiv" und sagte offen: "ein leeres Archiv ist das Auslieferungsergebnis." Patientendaten landeten auf dem Zielhost und blieben dort, bis ein Mensch eingriff.

3. Der Selbstwiderspruch, der aus beidem folgt. Ein DICOM-Archiv mit eigener Datenbank, das Patientendaten ohne Aufbewahrungsgrenze hält und keine Möglichkeit bietet, einen Zugriff einer Person zuzuordnen, ist Anwendungssoftware nach der eigenen Definition von Base - nicht knapp daneben, sondern genau das.

Drei Optionen, eine Entscheidung

Wir haben nicht direkt entfernt, sondern drei Wege geprüft. Die Audit- und Retention-Lücken selbst zu bauen, hätte bedeutet, dass Base Identitäts-/Audit-Zuständigkeiten übernimmt, die eigentlich zu der Anwendung gehören, die eine Klinik ohnehin schon betreibt (RIS, Viewer) - doppelte Arbeit, eine zweite, vermutlich inkonsistente Quelle der Wahrheit. Orthanc auf einen reinen Staging-Punkt mit Pflicht-Offload zu verengen, wäre technisch schlüssig gewesen, aber faktisch eine neue Funktion für automatisches Routing und Lifecycle-Management - kein Config-Change, ein neues Feature, für das uns die Praxiserfahrung im DICOM-Routing fehlt. Übrig blieb: entfernen, als externe Empfehlung dokumentieren, mit allen drei Befunden offen genannt statt sie jemandem gegen eine Produktivinstallation überlassen zu müssen.

Was das kostete

Ein Major-Version-Bump fünf Tage nach dem ersten Major-Release ist teuer - genau die Konsequenz, die unser eigenes Stabilitätsversprechen für einen entfernten Dienst vorsieht. Rollenname, Container-Namen, Deploy-Pfad und der Anteil an den eingefrorenen Variablen-, Alert- und Volume-Zahlen fielen weg. Kein Migrationspfad wurde gebaut - bewusst: Es gab zu diesem Zeitpunkt keine installierte Basis, die man hätte mitnehmen müssen, drei Tage nach dem v1.0.0-Tag. Eine Migration für hypothetische Installationen zu bauen, hätte bedeutet, Code zu pflegen, den niemand ausführt.

Was übrig bleibt, wenn man selbst Orthanc betreiben will

Die Entfernung ist keine Aussage gegen Orthanc als Projekt - sie ist eine Aussage darüber, was unsere Auslieferung davon tatsächlich war, gemessen statt angenommen. Wer trotzdem einen DICOM-Server neben Linumed Base betreiben will, bekommt die vollständigen Befunde mit auf den Weg: unprivilegierter Container ohne root, kein geteilter Standard-Account, DICOM-Port nie standardmäßig veröffentlicht, expliziter DicomModalities-Allowlist - und vor allem: die Frage nach Zugriffsidentität und Aufbewahrungsfrist vor dem ersten produktiven Bild klären, nicht danach.

Was das für Sie heißt

Wenn Sie einen Lieferanten für Ihre Klinik-IT bewerten, ist die interessante Frage selten, ob er Fehler macht - das tut jeder. Interessant ist, was passiert, wenn er einen findet: ob eine unbequeme Konsequenz (ein Major-Bump drei Tage nach dem ersten Release) tatsächlich gezogen wird, oder ob die eigene Regel im Zweifel doch nachgibt. Diese Geschichte ist der Beleg dafür, nicht die Ausnahme davon - die vollständige Begründung mit allen geprüften Alternativen steht offen einsehbar in ADR 0011, die Empfehlung für alle, die trotzdem einen DICOM-Server suchen, in docs/operations/orthanc-recommendation.md.

Mehr dazu: Linumed Base.