Paranoiczny konwejer przetwarzania MRI: model domenowy i pętla z klinicystą
Inżynieryjny obwód MRI Second Opinion przyjmuje dane DICOM, generuje szkic analizy w trybach voxel-backed lub metadata-fallback, przechodzi politykę bezpieczeństwa i obowiązkową recenzję lekarską przed finalizacją. Orkiestrator w TypeScript zarządza stanem sprawy, workerzy w Pythonie wykonują asynchroniczne przetwarzanie. Podział orkiestracji i obliczeń zapobiega OOM i timeoutom, rejestrując zdarzenia za pomocą Event Sourcing + Outbox.
Infrastruktura zamiast skryptów Jupyter
W rzeczywistych klinikach archiwa DICOM zawierają pliki bez rozszerzeń, niestandardowe prywatne tagi i JPEG 2000 Lossless, powodujące segfault w bibliotekach. Worker ingestyjny deterministycznie rozpakowuje dane, weryfikuje UID DICOM zgodnie z PS3.5 §9.1 i tworzy ImagingStudyRef. Przy niekompletnych skanach przechodzi w tryb metadata-fallback: wyciąga pytanie kliniczne z metadanych lub ustawia placeholder „Żądana rutynowa opinia drugiej strony”.
Workerzy ingestyjni i dostawczy rejestrują się w kontenerze DI, aktywowani flagą. To CDS (Clinical Decision Support), nie SaMD: DomainInvariantViolationError blokuje finalize() bez recenzji klinicysty zgodnie z wytycznymi FDA CDS section 520(o)(1)(E).
Kluczowe etapy konwejeru:
- Python-ingestion: tworzenie sprawy z metadanych DICOM.
- TypeScript-orkiestrator: inicjalizacja
MriSecondOpinionCase. - Python-processor: szkic w dwóch trybach.
- Polityka bezpieczeństwa: przejście do
AwaitingReview. - Recenzja ludzka: finalizacja przez lekarza.
- Dostawa: strukturyzowany raport.
Sztywne inwarianty w TypeScript
GenerateMriSecondOpinionUseCase stosuje IClinicalSafetyPolicy z flagami low confidence, significant disagreement, insufficient data. Opiera się na ACR Practice Parameters (Res. 11, 2020). Lekarz z rolą Neuroradiologist lub Attending Physician aktualizuje szkic; agregat rejestruje humanReview.modifications oddzielnie od szkicu AI.
Maszyna stanów: 9 statusów (INGESTING → QC_REJECTED, SUBMITTED → AWAITING_REVIEW → REVIEWED → FINALIZED → DELIVERY_PENDING → DELIVERED / DELIVERY_FAILED). 4 zarządzane przez agregat domenowy, 5 przez obwód przyjęcia/dostawy.
Podział orkiestracji i obliczeń
API TypeScript zwraca HTTP 200 natychmiast, asynchroniczny processor Python przejmuje zadania GPU. Kontrakty (port, token DI, polityka bezpieczeństwa) pozwalają wymienić adapter na multimodalny silnik bez przebudowy. Magazynowanie: SQLite lokalnie, PostgreSQL w produkcji.
Raport mapowany na HL7 FHIR R4 DiagnosticReport przez ImagingStudyRef, eksport do DICOM SR (SOP Class 1.2.840.10008.5.1.4.1.1.88.33). RadiologyReportSummary koduje RadLex (RSNA) i SNOMED CT. Rejestracja poprawek rozwiązuje problem dataset shift/model drift dla przyszłego douczenia.
Metryki i obserwowalność
Metryki Prometheus: liczniki/histogramy dla ingestion/processing/delivery, gauge mri_second_opinion_cases_awaiting_review (wg pilności) i mri_second_opinion_review_wait_started_at_unix. Powiadomienia o timeoutach w AwaitingReview dla krytycznych przypadków (udary).
Otwarty repozytorium: testy i workbench
Niezależne repozytorium z Dockerfile, docker-compose, SECURITY.md. 176/177 testów zielonych (state machine, PostgreSQL, autoryzacja). Pozycjonowane jako workflow clinician-in-the-loop, Research Use Only, bez pozwoleń regulacyjnych.
Możliwości wydania:
- Pełny cykl życia sprawy z powtórzeniami i audytem.
- Podział TypeScript (orkiestracja, walidacja, UI recenzenta) i Python (dyspozycja, fallback).
- Blokada dostawy bez recenzji.
- Metryki i eksport do standardów.
Co ważne
- Konwejer gwarantuje human-in-the-loop na poziomie kodu, blokując finalizację bez recenzji.
- Metadata-fallback zapobiega awariom na uszkodzonym DICOM.
- Podział obliczeń i orkiestracji ułatwia wymianę adaptera AI.
- FHIR/DICOM SR + RadLex/SNOMED zapewniają interoperacyjność.
- Metryki skupione na czasie recenzji dla ryzyk klinicznych.
— Editorial Team
Brak komentarzy.