Pipeline MRI segunda opinión: clinician-in-the-loop

Pipeline de Procesamiento de RM Paranoide: Modelo de Dominio y Bucle con Clínica en el Loop

El bucle de ingeniería de Segunda Opinión de RM ingiere datos DICOM, genera un análisis preliminar en modos respaldados por vóxeles o fallback a metadatos, pasa controles de seguridad y revisión obligatoria del clínico antes de la finalización. Un orquestador en TypeScript gestiona el estado del caso, mientras que workers en Python manejan el procesamiento asíncrono. Separar la orquestación de la computación evita errores de memoria y timeouts, registrando eventos mediante Event Sourcing + Outbox.

Infraestructura por Encima de Scripts de Jupyter

En clínicas reales, los archivos DICOM suelen incluir ficheros sin extensiones, etiquetas privadas personalizadas y JPEG 2000 sin pérdidas que provocan fallos segfault en las librerías. El worker de ingesta desempaqueta los datos de forma determinística, valida UIDs DICOM según PS3.5 §9.1 y crea un ImagingStudyRef. Para escaneos incompletos, pasa a fallback de metadatos: extrae la pregunta clínica de los metadatos o usa por defecto “Solicitada revisión de segunda opinión rutinaria”.

Los workers de ingesta y entrega se registran en un contenedor DI y se activan vía flags. Esto es CDS (Soporte a la Decisión Clínica), no SaMD: DomainInvariantViolationError bloquea finalize() sin revisión clínica, según la guía FDA CDS sección 520(o)(1)(E).

Etapas clave del pipeline:

• Python-ingesta: Creación del caso desde metadatos DICOM.
• TypeScript-orquestador: Inicializa MriSecondOpinionCase.
• Python-procesador: Borrador en dos modos.
• Política de seguridad: Pasa a AwaitingReview.
• Revisión humana: Finalización por el médico.
• Entrega: Informe estructurado.

Invariantes Estrictos en TypeScript

GenerateMriSecondOpinionUseCase aplica IClinicalSafetyPolicy con flags para baja confianza, desacuerdo significativo o datos insuficientes. Se basa en los Parámetros de Práctica ACR (Res. 11, 2020). Médicos con roles Neuroradiólogo o Médico Titular actualizan el borrador; el agregado rastrea humanReview.modifications por separado del borrador de IA.

Máquina de estados: 9 estatus (INGESTING → QC_REJECTED, SUBMITTED → AWAITING_REVIEW → REVIEWED → FINALIZED → DELIVERY_PENDING → DELIVERED / DELIVERY_FAILED). 4 gestionados por el agregado de dominio, 5 por bucles de ingesta/entrega.

Separando Orquestación de Computación

La API TypeScript devuelve HTTP 200 al instante, mientras los procesadores Python asíncronos abordan tareas de GPU. Contratos (puerto, token DI, política de seguridad) permiten intercambiar adaptadores para motores multimodales sin recompilaciones. Almacenamiento: SQLite local, PostgreSQL en producción.

Los informes mapean a HL7 FHIR R4 DiagnosticReport vía ImagingStudyRef, con exportación a DICOM SR (SOP Class 1.2.840.10008.5.1.4.1.1.88.33). RadiologyReportSummary usa RadLex (RSNA) y SNOMED CT. Capturar ediciones aborda el desplazamiento de dataset/drift del modelo para reentrenamientos futuros.

Métricas y Observabilidad

Métricas Prometheus: contadores/histogramas para ingesta/procesamiento/entrega, gauges como mri_second_opinion_cases_awaiting_review (por urgencia) y mri_second_opinion_review_wait_started_at_unix. Alertas por timeouts en AwaitingReview para casos críticos (ictus).

Repo Abierto: Pruebas y Banco de Trabajo

Repo independiente con Dockerfile, docker-compose, SECURITY.md. 176/177 pruebas aprobadas (máquina de estados, PostgreSQL, auth). Posicionado como flujo de trabajo con clínico en el bucle, Uso en Investigación únicamente, sin aprobaciones regulatorias.

Características del lanzamiento:

• Ciclo de vida completo del caso con reintentos y auditoría.
• Separación TypeScript (orquestación, validación, UI revisor) y Python (despacho, fallback).
• Bloquea entrega sin revisión.
• Métricas y exportación a estándares.

Lecciones Clave

• El pipeline impone humano-en-el-bucle a nivel de código, bloqueando finalización sin revisión.
• Fallback a metadatos evita fallos en DICOM corruptos.
• Separar computación y orquestación simplifica cambios de adaptadores IA.
• FHIR/DICOM SR + RadLex/SNOMED asegura interoperabilidad.
• Métricas enfocadas en tiempos de revisión para gestión de riesgos clínicos.

— Editorial Team