Pipeline paranoïaque de traitement IRM : Modèle de domaine et boucle clinicien
La boucle d'ingénierie de deuxième avis IRM ingère les données DICOM, génère une analyse préliminaire en modes voxel ou métadonnées de secours, passe des contrôles de sécurité et une revue obligatoire par un clinicien avant finalisation. Un orchestrateur TypeScript gère l'état des cas, tandis que des workers Python traitent les tâches asynchrones. La séparation de l'orchestration et du calcul évite les erreurs de mémoire et les timeouts, en journalisant les événements via Event Sourcing + Outbox.
Infrastructure au-delà des scripts Jupyter
Dans les vraies cliniques, les archives DICOM contiennent souvent des fichiers sans extension, des tags privés personnalisés et du JPEG 2000 sans perte qui font planter les bibliothèques avec des segfaults. Le worker d'ingestion décompresse les données de manière déterministe, valide les UID DICOM selon PS3.5 §9.1, et crée une ImagingStudyRef. Pour les scans incomplets, il passe en mode métadonnées de secours : extraction de la question clinique des métadonnées ou défaut à « Demande de revue de routine pour deuxième avis ».
Les workers d'ingestion et de livraison s'enregistrent dans un conteneur DI et s'activent via des flags. C'est du CDS (soutien à la décision clinique), pas du SaMD : DomainInvariantViolationError bloque finalize() sans revue clinicienne, conformément aux directives FDA CDS §520(o)(1)(E).
Étapes clés du pipeline :
- Python-ingestion : Création du cas à partir des métadonnées DICOM.
- TypeScript-orchestrator : Initialisation de
MriSecondOpinionCase. - Python-processor : Brouillon en deux modes.
- Politique de sécurité : Passage à
AwaitingReview. - Revue humaine : Finalisation par le médecin.
- Livraison : Rapport structuré.
Invariants stricts en TypeScript
GenerateMriSecondOpinionUseCase applique IClinicalSafetyPolicy avec des flags pour faible confiance, désaccord significatif ou données insuffisantes. Il s'inspire des Paramètres de pratique ACR (Res. 11, 2020). Les médecins avec rôles Neuroradiologue ou Médecin senior mettent à jour le brouillon ; l'agrégat suit humanReview.modifications séparément du brouillon IA.
Machine d'état : 9 statuts (INGESTING → QC_REJECTED, SUBMITTED → AWAITING_REVIEW → REVIEWED → FINALIZED → DELIVERY_PENDING → DELIVERED / DELIVERY_FAILED). 4 gérés par l'agrégat de domaine, 5 par les boucles d'admission/livraison.
Séparation de l'orchestration et du calcul
L'API TypeScript renvoie HTTP 200 instantanément, tandis que les processeurs Python asynchrones gèrent les tâches GPU. Les contrats (port, token DI, politique de sécurité) permettent de swapping les adaptateurs pour moteurs multimodaux sans recompilation. Stockage : SQLite en local, PostgreSQL en production.
Les rapports cartographient vers HL7 FHIR R4 DiagnosticReport via ImagingStudyRef, avec export vers DICOM SR (SOP Class 1.2.840.10008.5.1.4.1.1.88.33). RadiologyReportSummary utilise RadLex (RSNA) et SNOMED CT. La capture des éditions adresse le décalage de dataset/dérive de modèle pour les réentraînements futurs.
Métriques et observabilité
Métriques Prometheus : compteurs/histogrammes pour ingestion/traitement/livraison, jauges comme mri_second_opinion_cases_awaiting_review (par urgence) et mri_second_opinion_review_wait_started_at_unix. Alertes sur timeouts en AwaitingReview pour cas critiques (AVC).
Repo ouvert : Tests et banc d'essai
Repo autonome avec Dockerfile, docker-compose, SECURITY.md. 176/177 tests passing (machine d'état, PostgreSQL, auth). Positionné comme workflow clinicien-in-the-loop, usage recherche uniquement, sans approbations réglementaires.
Fonctionnalités de sortie :
- Cycle de vie complet du cas avec retries et audit.
- Séparation TypeScript (orchestration, validation, UI relecteur) et Python (dispatch, fallback).
- Blocage de livraison sans revue.
- Métriques et export standards.
Points clés à retenir
- Le pipeline impose l'humain-in-the-loop au niveau code, bloquant la finalisation sans revue.
- Mode métadonnées de secours évite les crashes sur DICOM corrompus.
- Séparation calcul/orchestration simplifie les swaps d'adaptateurs IA.
- FHIR/DICOM SR + RadLex/SNOMED assure l'interopérabilité.
- Métriques ciblent les temps de revue pour gestion des risques cliniques.
— Editorial Team
Aucun commentaire pour le moment.