// PANEL PRINCIPAL
Visión general del ecosistema de imagen médica · Métricas clave de rendimiento
SWF
Perfil IHE activo
30-50%
Reducción errores con MWL
TAT
Turnaround Time (KPI#1)
0
Estudios huérfanos objetivo
📊 KPIs del Servicio Radiológico
🔄 Estado del Flujo en Tiempo Real
✓HIS → RIS: ORM O01 fluyendo correctamente
✓MWL (C-FIND): Worklist activa en todas las modalidades
⚠MPPS: 3 estudios sin confirmación COMPLETED en TC-1
ℹHL7 ORU: Cola de 7 mensajes pendientes de entrega
!VNA sync: Latencia elevada detectada (revisar red)
🏥 Arquitectura del Sistema
1
Capa HIS/EHR — Órdenes clínicas, admisiones ADT, facturación
2
Motor de interfaz — Mirth Connect / Rhapsody: traduce y enruta
3
PACS/VNA — Almacena, indexa y distribuye imágenes DICOM
4
Modalidades — TC, RM, Rx, US: adquieren y transmiten vía C-STORE
📋 Tareas del Día
!
Urgente: Reconciliar 3 estudios sin MPPS en modalidad TC-1
2
Media: Verificar AETitle de nuevo equipo Rx instalado hoy
3
Normal: Auditoría mensual de tags DICOM (Patient ID, Accession)
4
Planificado: Reunión con equipo Rhapsody — upgrade v7.2
⚡ Accesos Rápidos
→ Ver flujo SWF interactivo
→ Protocolo de crisis
→ Checklist DICOM
→ Glosario técnico
→ Escenarios con IA adversaria
🤖 Abrir panel agéntico
// FLUJO IHE SCHEDULED WORKFLOW (SWF)
La columna vertebral de la informática radiológica · Click en cada nodo para consultar al agente
Pipeline completo — 5 etapas críticas
Cargando diagrama SVG...
① HIS/RIS → ORM O01 — El génesis del dato
M
MSH → cabecera: emisor, receptor, timestamp, ID único del mensaje
P
PID → identidad del paciente. Si va vacío o mal: PACIENTE FANTASMA en el PACS
V
PV1 → datos de la visita, tipo de ingreso, médico referente
O
OBR → la prueba solicitada: tipo, urgencia, Accession Number
⚠Fallo crítico: PID vacío rompe el MPI → duplicidad de registros y error de facturación
② MWL (DICOM C-FIND) — El filtro de eficiencia
La modalidad consulta la worklist al arrancar. El técnico ve al paciente precargado sin teclear nada.
⚠Fallo top #1: AETitle incorrecto → modalidad ciega a la worklist
SCU = Modalidad
SCP = Servidor MWL
AETitle: máx 16 chars, case-sensitive
③ DICOM C-STORE — El nacimiento de la imagen
Tags OBLIGATORIOS en cada objeto DICOM:
| Tag | Nombre | Impacto si falla |
|---|---|---|
| (0010,0020) | Patient ID | Estudio huérfano |
| (0020,000D) | Study Instance UID | No vincula con orden |
| (0008,0060) | Modality | Clasificación errónea |
| (0008,0050) | Accession Number | Sin vínculo con RIS |
④ MPPS — El gran olvidado (pero crítico)
IN PROGRESS→COMPLETED→RIS (cierra orden)
Sin MPPS: el RIS no sabe si la prueba se realizó → KPIs incorrectos → facturación afectada
⑤ HL7 ORU R01 — Cierre del ciclo clínico
PACS/RIS→ORU R01→HCE médico
Sin OBX correcto: informe sin imagen en la HCE → médico no puede acceder a las imágenes desde el historial
// DICOM — REFERENCIA TÉCNICA
Digital Imaging and Communications in Medicine · Comandos, tags y troubleshooting
Comandos DICOM (DIMSE)
| Comando | Función | Uso típico |
|---|---|---|
| C-ECHO | Ping DICOM | Verificar conectividad |
| C-STORE | Enviar objeto | Modalidad → PACS |
| C-FIND | Buscar/consultar | MWL, Query PACS |
| C-MOVE | Mover estudio | PACS → estación |
| C-GET | Recuperar objeto | Descarga directa |
| N-ACTION | Acción en objeto | MPPS control |
Jerarquía del objeto DICOM
P
Patient — Patient ID (0010,0020), Patient Name (0010,0010)
S
Study — Study Instance UID (0020,000D), Accession Number (0008,0050)
S
Series — Series Instance UID (0020,000E), Modality (0008,0060)
I
Instance (SOP) — SOP Instance UID (0008,0018), SOP Class UID
Transfer Syntax más comunes
1
1.2.840.10008.1.2.1
Explicit VR Little Endian (estándar)
Explicit VR Little Endian (estándar)
2
1.2.840.10008.1.2.4.70
JPEG Lossless (diagnóstico, sin pérdida)
JPEG Lossless (diagnóstico, sin pérdida)
3
1.2.840.10008.1.2.4.91
JPEG 2000 Lossless (compresión alta)
JPEG 2000 Lossless (compresión alta)
Checklist de Troubleshooting
1
¿C-ECHO responde entre modalidad y PACS?
2
¿AETitle y puerto correctos en ambos lados?
3
¿Espacio en disco suficiente en PACS?
4
¿SOP Class aceptado por el PACS SCP?
5
¿Transfer Syntax compatible?
6
¿Study UID coincide con el del RIS?
DICOMweb (Cloud/Browser)
WADO-RS → Retrieve imágenes vía HTTP
STOW-RS → Store imágenes vía HTTP POST
QIDO-RS → Query/Search vía HTTP GET
Base de PACS cloud, visores web y APIs de IA.
// HL7 v2 / FHIR — MENSAJERÍA CLÍNICA
Estándares de interoperabilidad · v2 legacy + FHIR R4 moderno
HL7 v2.x — Mensajes críticos
| Mensaje | Trigger | Uso en imagen médica |
|---|---|---|
| ADT A01 | Admit | Ingreso paciente → crea registro |
| ADT A03 | Discharge | Alta paciente |
| ADT A08 | Update | Cambio de datos demográficos |
| ORM O01 | Order | Solicitud de prueba de imagen |
| ORU R01 | Result | Informe radiológico al HCE |
| ACK | Acknowledge | Confirmación de recepción |
Estructura real de un mensaje HL7
MSH|^~\&|RIS|HOSPITAL|PACS|DEST|20260511||ORM^O01|MSG001|P|2.5
PID|1||12345^^^MPI||GARCIA^JUAN||19800101|M
PV1|1|I|RAD^01^A|||DR_LOPEZ
ORC|NW|ORD20260511001|||||||DR_SMITH
OBR|1|ORD001||RX-TORAX^Rx Tórax PA||20260511
PID|1||12345^^^MPI||GARCIA^JUAN||19800101|M
PV1|1|I|RAD^01^A|||DR_LOPEZ
ORC|NW|ORD20260511001|||||||DR_SMITH
OBR|1|ORD001||RX-TORAX^Rx Tórax PA||20260511
ℹPregunta trampa: OBR = la prueba · OBX = cada observación/resultado individual dentro de esa prueba
FHIR R4 — Recursos en imagen
IS
ImagingStudy — Representa el estudio completo, vincula con DICOM
SR
ServiceRequest — La orden de imagen (equivale al ORM)
DR
DiagnosticReport — El informe (equivale al ORU)
P
Patient — Demographics del paciente
HL7 v2 vs FHIR — cuándo usar cada uno
| HL7 v2 | FHIR R4 | |
|---|---|---|
| Formato | Pipes/segmentos | JSON/XML REST |
| Entornos | Legacy HIS/RIS | Cloud, móvil, apps |
| Imagen | ORM/ORU | ImagingStudy API |
| IA/LLM | Difícil consumo | Nativo REST |
Segmentos clave ORU R01
M
MSH — Cabecera: origen, destino, tipo de mensaje
P
PID — Identidad del paciente
O
OBR — La prueba informada
X
OBX — Cada hallazgo/observación del informe
⚠Sin OBX bien mapeado: médico ve texto pero no puede acceder a las imágenes
🔬 Analizador de Mensajes HL7 — Pega aquí tu mensaje real
El agente parsea segmento a segmento, detecta campos vacíos o mal formateados y calcula el impacto clínico de cada error. Se carga un mensaje de ejemplo real:
Funciona con ORM, ORU, ADT o cualquier mensaje v2.x
// PACS / VNA — ALMACENAMIENTO Y DISTRIBUCIÓN
Picture Archiving · Vendor Neutral Archive · Arquitectura de imagen empresarial
PACS — Interfaz de trabajo radiológico
W
Worklist engine — Lista de lectura del radiólogo. Con IA: prioriza urgentes automáticamente
V
Visor diagnóstico — 2D/3D, MPR, herramientas de medición
R
Reporting tools — Dictado, voice recognition, plantillas estructuradas
A
Almacén local — Short-term. Imágenes recientes de alta velocidad
VNA — Repositorio empresarial neutro
N
Vendor Neutral — Formato estándar, no propietario
L
Long-term archive — Retención normativa 7-10 años (Europa)
M
Multi-PACS — Un VNA sirve a radiología, cardiología, oncología
R
Redundancia geo — Replicación activa-activa entre centros
✓Estrategia: PACS como interfaz + VNA como cerebro de almacenamiento
// MOTORES DE INTERFAZ — MIRTH vs RHAPSODY
Comparativa técnica y económica · Cuándo usar cada uno
Mirth Connect
Rhapsody
Licencia
Open Source (MPL) + soporte comercial
Propietario — Orion Health
Lógica de interfaz
JavaScript (scripting)
Visual drag-and-drop
Alta disponibilidad
Manual (balanceador / K8s)
Nativa Activo-Activo
Tiempo despliegue
Variable (según experiencia)
6-12 semanas
Costo 3 años
Bajo-Medio
$600K - $1.6M
Ideal para
Equipos técnicos, hospitales medianos
>500 camas, redes distribuidas
// PERFILES IHE — ORQUESTACIÓN DE LA INTEROPERABILIDAD
IHE no es un estándar: es la gramática que define cómo usar DICOM + HL7 juntos en escenarios reales
Perfiles de Infraestructura Radiológica
| Perfil | Qué resuelve |
|---|---|
| SWF | Scheduled Workflow — columna vertebral del flujo RIS↔PACS |
| MPPS | Notificación de procedimiento realizado → cierre de orden en RIS |
| PIX | Patient ID Cross-referencing — mantiene MPI robusto |
| PDQ | Patient Demographics Query — busca datos demográficos |
| ATNA | Audit Trail — trazabilidad y autenticación (HIPAA/GDPR) |
| XDS.b | Cross-Enterprise Document Sharing — repositorios regionales |
| XCA | Cross-Community Access — interoperabilidad transfronteriza |
El principio fundamental IHE
💡HL7 y DICOM = el vocabulario. IHE = la gramática y el protocolo de actuación.
S
Estándar DICOM define cómo enviar una imagen (C-STORE)
P
Perfil IHE SWF define CUÁNDO enviarla, en qué orden, y qué debe pasar antes y después
Connectathons: Eventos donde se valida que distintos fabricantes sean realmente interoperables bajo los perfiles IHE.
// IA & TRIAJE AUTOMÁTICO
Inteligencia artificial en el ecosistema radiológico cognitivo · AI Act 2024 · MLOps
Los 5 Agentes del Ecosistema Cognitivo
1
Coordinador Administrativo: Valida órdenes HL7, optimiza agendas, notificaciones personalizadas
2
Co-Piloto Técnico: Sugiere protocolos desde la worklist, QA en tiempo real durante adquisición
3
Clasificador de Urgencias:
Triaje de patologías críticas (ej. ACV, Neumotórax) priorizando la worklist del radiólogo.
4
Ayudante del Radiólogo: Mediciones automáticas, segmentación y borrador de informe (Structured Reporting).
5
Auditor de Calidad: Revisión de TAT, discrepancias diagnósticas y codificación automática para facturación.
// CARDIOLOGÍA DIGITAL
C-PACS, Waveforms y DICOM Structured Reporting
Diferencias Críticas con Radiología
1
Multiframe y Waveforms: Estudios ecocardiográficos (vídeos) y ECGs nativos DICOM.
2
SR Complejos: Árboles de mediciones hemodinámicas muy extensos (DICOM Structured Reporting).
// GESTIÓN DE CRISIS
Protocolos de actuación rápida ante caídas de sistemas e interrupciones del servicio
⚡ Síntoma → Primer diagnóstico
| Síntoma que reporta el técnico | Primer diagnóstico |
|---|---|
| Modalidad no ve worklist | AETitle incorrecto · verificar C-ECHO |
| Estudios no llegan al PACS | C-STORE fallido · logs PACS · disco lleno |
| Pacientes duplicados en worklist | Problema MPI · ADT A08 no llegó |
| ORU no llega al HCE | Cola HL7 bloqueada · OBR/OBX sin mapear |
| Estudio sin orden en PACS | Study UID diferente al del RIS |
| RIS no cierra la orden | MPPS no enviado o rechazado por RIS |
| TAT de RM el doble que TC | Mapear proceso real: ¿dónde espera el estudio? |
📶 Escalación correcta L1 / L2 / L3
L1
Soporte básico: C-ECHO, restart servicio,
verificar logs básicos. Sin necesidad de arquitectura HL7/DICOM.
L2
Consultor: Diagnóstico profundo, troubleshooting HL7/DICOM,
coordinación entre sistemas y fabricantes. Aquí entras tú.
L3
Fabricante: Bug confirmado, problema de versión, corrupción de BD.
Siempre con ticket documentado y RCA previo.
💡
Principio clave: workaround antes que fix.
El clínico necesita operar ahora. El fix permanente puede esperar.
🚨 Caída de PACS / Servidor Principal
1. Activar modo contingencia en modalidades.
2. Impresión DICOM o quemado en CD si es crítica vital.
3. Notificar a Urgencias e IT.
// SEGURIDAD & COMPLIANCE
RGPD, HIPAA, Perfil IHE ATNA y normativas aplicables
Auditoría ATNA (Audit Trail and Node Authentication)
Trazabilidad inmutable y completa de accesos (quién vio qué estudio, cuándo y desde dónde). Encriptación TLS mandatoria en nodos DICOM.
// GLOSARIO TÉCNICO
Diccionario interactivo de interoperabilidad médica
Navega por las demás secciones de la plataforma y pasa el cursor por las etiquetas resaltadas (ej: AETitle o MWL) para invocar los tooltips dinámicos vinculados al agente IA.
📐 Estándares
| DICOM | Imágenes médicas: almacenamiento, transmisión, visualización |
| HL7 v2 | Mensajería clínica y administrativa punto a punto (MLLP) |
| FHIR R4 | API RESTful moderna: JSON/XML, cloud, mobile, IA |
| IHE | Perfiles de integración: cómo usar DICOM+HL7 juntos en escenarios reales |
| LOINC | Códigos de observaciones y pruebas clínicas (laboratorio, imagen) |
| SNOMED CT | Terminología clínica: diagnósticos, síntomas, procedimientos |
🏥 Sistemas
| PACS | Archivo y comunicación de imagen médica (core del servicio) |
| VNA | Archivo neutro de proveedor (largo plazo, 7-10 años) |
| RIS | Sistema de información radiológica: órdenes, informes, TAT |
| HIS | Sistema de información hospitalaria: admisiones, facturación |
| EHR / HCE | Historia clínica electrónica del paciente |
| MPI | Master Patient Index: ID único e irrepetible entre sistemas |
⚙️ Componentes técnicos
| AETitle | "Dirección postal" DICOM (≤16 chars, case-sensitive, sin espacios finales) |
| SCP | Service Class Provider: el servidor que recibe la petición DICOM |
| SCU | Service Class User: el cliente que inicia la petición DICOM |
| SOP Class | Tipo de objeto DICOM (CT Image Storage, RT Plan, SR…) |
| MLLP | Protocolo de transporte de mensajes HL7 (sobre TCP/IP) |
| MWL | Modality Worklist: lista de trabajo DICOM precargada en la modalidad |
| MPPS | Modality Performed Procedure Step: notificación de estudio realizado |
| DICOM SR | Structured Reporting: medidas estructuradas en cardiología y oncología |
| TAT | Turnaround Time: KPI#1 en radiología (orden → informe, objetivo <2h urgentes) |
📊 Métricas clave del consultor
| KPI | Definición | Objetivo operativo |
|---|---|---|
| TAT | Turnaround Time: desde orden hasta informe firmado | <2h urgentes · <24h electivos |
| SLA PACS | Disponibilidad del sistema de archivo | ≥ 99.9% |
| RTO | Recovery Time Objective: tiempo máximo de restauración | < 4h |
| RPO | Recovery Point Objective: máxima pérdida de datos aceptable | < 1h |
| MWL hit rate | Estudios con worklist correctamente precargada | > 95% |
| MPPS rate | Estudios con MPPS completado (cierre de orden en RIS) | > 98% |
// GUÍA ESCENARIOS: ADVERSARIO IA
Prepárate con escenarios técnicos en Informática Médica simulando un evaluador experto.
Pulsa Iniciar escenario para comenzar el simulacro interactivo.
// FLUJO ANTE INCIDENTES (RTO)
Protocolo de Recuperación · Minimizar Tiempo de Recuperación (RTO) ante fallos de comunicación de datos
⚡ 5 Fases Críticas — Diagnóstico al RCA
Cargando diagrama RTO...
⚡ Simulador de Incidentes
⚡DICOM C-FIND timeout en todas las modalidades
⚡HL7 ORU: Cola acumulada 250+ mensajes sin entregar
🔴URGENCIA ACTIVA: Estudios urgentes pendientes (4 órdenes)
📊 Métricas & Objetivos
| Métrica | Definición | Objetivo |
|---|---|---|
| RTO | Recovery Time Objective: máximo tiempo permitido de inactividad | ≤15 min (crítico) |
| RPO | Recovery Point Objective: máximo volumen de datos que se puede perder | ≤1 min (cero pérdida) |
| MTTR | Mean Time To Repair: tiempo promedio para reparación | ≤10 min operacional |
| Disponibilidad | % de tiempo que el sistema responde sin errores | 99.5% durante horario operativo |
5 Fases del Protocolo
1
Detección: Identificar síntoma exacto
2
Triaje: ¿Hay urgencias? ¿Scope del impacto?
3
Aislamiento: ¿Cliente o servidor? ¿Red u app?
4
Remediación: Playbook escalonado (reconexión → restart → failover)
5
RCA: Documentar timeline, causa raíz, prevención
// CONTINUIDAD DEL SERVICIO (SLA 99.9%)
Estrategia de Mantenimiento Preventivo · Maximizar la Disponibilidad del Sistema
🛡️ 5 Pilares de Continuidad — Arquitectura Resiliente
Cargando diagrama de Continuidad...
🛡️ Monitoreo & Alertas Proactivas
✓API Gateway: latencia p95 <200ms (nominal)
✓Database: conexiones <70% del máximo (nominal)
⚠️Disco disponible: 22% (umbral 20%, acción requierida)
ℹ️Replicación: lag <1.5 segundos (excelente)
📈 Niveles de SLA & Disponibilidad
| Nivel | Disponibilidad | Downtime/año | Requisito de Infraestructura |
|---|---|---|---|
| 99.9% (3 nines) | 99.9% | 8.7 h/año | 1 DC + backup manual |
| 99.99% (4 nines) | 99.99% | 52 min/año | Redundancia local + failover automático |
| 99.999% (5 nines) | 99.999% | 5.2 min/año | Multi-DC activo-activo + replicación RT |
5 Pilares de Continuidad
1
Monitoreo: Alertas antes de falla (CPU, memoria, latencia)
2
Mantenimiento: Updates planificadas sin downtime (blue-green)
3
Redundancia: Multi-DC activo-activo con replicación <2s
4
Backups: 3-2-1 (3 copias, 2 medios, 1 offsite, testeo mensual)
5
Simulacros: Ejercicios trimestrales de DR y failover
Matriz de Flujos de Trabajo
Comparativa HL7 v2.x (ORM/ORU) vs. DICOM (C-STORE/C-FIND) en pipeline IA · YKONOS VIII
HL7
v2.x / FHIR R4
DICOM
3.0 / DICOMweb
AI
Inference Node
IHE
XDS / RIS-PACS
Etapas de Integración DICOM/HL7
| ETAPA | HL7 · ORM/ORU | DICOM · C-STORE/C-FIND |
|---|---|---|
| Solicitud/Order | ORM^O01 — RIS genera mensaje con Accession Number | Modality Worklist — Modalidad consulta PACS antes de adquirir |
| Adquisición | ORM^O01 update — Estatus en HIS/RIS | C-STORE — Imágenes al PACS |
| Inferencia IA | Trigger HL7 — ACK dispara motor IA | C-FIND → Pull — Nodo IA obtiene imágenes |
Diccionario de Tags DICOM Críticos
Haz clic en cualquier tag para expandir su función en YKONOS VIII
Troubleshooting DICOM/HL7
Selecciona un error para ver causa raíz y solución
ERRORES DICOM
ERRORES HL7
ERRORES IA
👆
Selecciona un error para ver el diagnóstico
Checklist de Interoperabilidad
Verificación previa al despliegue de nodos de IA
0
completados
PROGRESO TOTAL
0%
Speech de Escenarios
Los pilares para posicionarte como Consultor Senior en Interoperabilidad