Paranoide MRI-Verarbeitungspipeline: Domänenmodell und Kliniker-in-the-Loop
Die MRI Second Opinion-Entwicklungs-Schleife verarbeitet DICOM-Daten, erzeugt eine Entwurfsanalyse im Voxel-basierten oder Metadaten-Fallback-Modus, durchläuft Sicherheitsprüfungen und obligatorische Überprüfung durch Kliniker vor der Finalisierung. Ein TypeScript-Orchestrator verwaltet den Fallstatus, während Python-Worker asynchrone Verarbeitung übernehmen. Die Trennung von Orchestrierung und Berechnung verhindert Speichermangel und Timeouts, mit Event-Logging über Event Sourcing + Outbox.
Infrastruktur statt Jupyter-Skripte
In echten Kliniken enthalten DICOM-Archive oft Dateien ohne Erweiterung, kundenspezifische private Tags und JPEG 2000 Lossless, die Bibliotheken mit Segmentierungsfehlern abstürzen lassen. Der Ingestion-Worker entpackt Daten deterministisch, validiert DICOM-UIDs gemäß PS3.5 §9.1 und erstellt eine ImagingStudyRef. Bei unvollständigen Scans wechselt er in den Metadaten-Fallback: Extrahiert die klinische Frage aus Metadaten oder setzt standardmäßig „Routine-Zweitmeinung angefordert“.
Ingestion- und Delivery-Worker registrieren sich in einem DI-Container und aktivieren sich per Flags. Dies ist CDS (Clinical Decision Support), kein SaMD: DomainInvariantViolationError blockiert finalize(), solange keine Kliniker-Überprüfung erfolgt – gemäß FDA-CDS-Richtlinie Abschnitt 520(o)(1)(E).
Wichtige Pipeline-Phasen:
- Python-Ingestion: Fall-Erstellung aus DICOM-Metadaten.
- TypeScript-Orchestrator: Initialisierung von
MriSecondOpinionCase. - Python-Processor: Entwurf in zwei Modi.
- Sicherheitsrichtlinie: Übergang zu
AwaitingReview. - Manuelle Überprüfung: Finalisierung durch Arzt.
- Auslieferung: Strukturierter Bericht.
Strenge Invarianten in TypeScript
GenerateMriSecondOpinionUseCase wendet IClinicalSafetyPolicy mit Flags für geringes Vertrauen, starke Abweichungen oder unzureichende Daten an. Basierend auf ACR Practice Parameters (Res. 11, 2020). Ärzte mit Rollen Neuroradiologe oder Oberarzt bearbeiten den Entwurf; das Aggregat trackt humanReview.modifications getrennt vom KI-Entwurf.
Zustandsmaschine: 9 Status (INGESTING → QC_REJECTED, SUBMITTED → AWAITING_REVIEW → REVIEWED → FINALIZED → DELIVERY_PENDING → DELIVERED / DELIVERY_FAILED). 4 verwaltet vom Domänen-Aggregat, 5 von Intake/Delivery-Schleifen.
Trennung von Orchestrierung und Berechnung
TypeScript-API liefert sofort HTTP 200, während asynchrone Python-Processor GPU-Aufgaben bewältigen. Verträge (Port, DI-Token, Sicherheitsrichtlinie) erlauben Adapter-Wechsel für multimodale Engines ohne Neukompilierung. Speicher: SQLite lokal, PostgreSQL in Produktion.
Berichte werden auf HL7 FHIR R4 DiagnosticReport via ImagingStudyRef abgebildet, mit Export zu DICOM SR (SOP Class 1.2.840.10008.5.1.4.1.1.88.33). RadiologyReportSummary nutzt RadLex (RSNA) und SNOMED CT. Erfassung von Bearbeitungen adressiert Dataset-Shift/Model-Drift für zukünftiges Retraining.
Metriken und Observability
Prometheus-Metriken: Zähler/Histogramme für Ingestion/Processing/Delivery, Gauges wie mri_second_opinion_cases_awaiting_review (nach Dringlichkeit) und mri_second_opinion_review_wait_started_at_unix. Alarme bei Timeouts in AwaitingReview für kritische Fälle (Schlaganfall).
Offenes Repo: Tests und Workbench
Eigenständiges Repo mit Dockerfile, docker-compose, SECURITY.md. 176/177 Tests bestanden (Zustandsmaschine, PostgreSQL, Auth). Positioniert als Kliniker-in-the-Loop-Workflow, Research Use Only, keine regulatorischen Zulassungen.
Release-Features:
- Vollständiger Fall-Lebenszyklus mit Retries und Audit.
- Getrennt TypeScript (Orchestrierung, Validierung, Reviewer-UI) und Python (Dispatch, Fallback).
- Blockiert Auslieferung ohne Überprüfung.
- Metriken und Standards-Export.
Wichtige Erkenntnisse
- Pipeline erzwingt Kliniker-in-the-Loop auf Code-Ebene, blockiert Finalisierung ohne Review.
- Metadaten-Fallback vermeidet Abstürze bei defekten DICOMs.
- Trennung von Compute und Orchestrierung vereinfacht KI-Adapter-Wechsel.
- FHIR/DICOM SR + RadLex/SNOMED gewährleistet Interoperabilität.
- Metriken zielen auf Review-Zeiten für klinisches Risikomanagement ab.
— Editorial Team
Noch keine Kommentare.