El Flujo de Trabajo de Órdenes de Radiología
Cuando un médico ordena un examen de radiología — una tomografía, resonancia magnética, radiografía o ecografía — la orden se origina en el sistema de Historia Clínica Electrónica (HCE) y debe viajar a través de varios sistemas antes de que el paciente llegue al escáner. El mensaje HL7 ORM^O01 es la transacción estándar que transporta esta orden desde el HCE al Sistema de Información Radiológica (RIS). El RIS, a su vez, llena el DICOM Modality Worklist (MWL), que la modalidad de imagen consulta para obtener información del paciente y del examen. Entender esta cadena — HCE → HL7 ORM → RIS → DICOM MWL → Modalidad — es fundamental para cualquier persona que trabaje en integración de imágenes médicas.
Anatomía de un Mensaje ORM^O01
Un mensaje HL7 ORM^O01 (Mensaje de Orden) contiene varios segmentos clave que transportan los datos necesarios para construir una entrada de worklist:
- MSH (Encabezado del Mensaje): Identifica las aplicaciones emisora y receptora, tipo de mensaje (ORM^O01), marca de tiempo y versión HL7.
- PID (Identificación del Paciente): Contiene el MRN del paciente (PID-3), nombre (PID-5), fecha de nacimiento (PID-7) y sexo (PID-8). Estos se mapean directamente a los tags DICOM Patient ID, Patient Name, Birth Date y Sex.
- PV1 (Visita del Paciente): Lleva la clase del paciente (hospitalizado, ambulatorio, urgencias), ubicación (PV1-3), médico tratante (PV1-7) y médico referente (PV1-8).
- ORC (Orden Común): Contiene el código de control de orden (ORC-1: NW para nueva, CA para cancelar, XO para cambiar), número de orden del solicitante (ORC-2) y médico solicitante (ORC-12).
- OBR (Solicitud de Observación): El segmento central para órdenes de radiología. OBR-4 lleva el código y descripción del procedimiento, OBR-16 el médico solicitante, OBR-18 el número de acceso (crítico para el enlace de estudio DICOM) y OBR-27 la fecha/hora programada y prioridad.
El Mapeo HL7-a-DICOM
El RIS transforma los datos HL7 ORM en atributos DICOM Modality Worklist. Los mapeos clave incluyen:
- PID-3 → (0010,0020) Patient ID: El MRN se convierte en el DICOM Patient ID, usado por la modalidad para asociar el estudio con el registro correcto del paciente.
- PID-5 → (0010,0010) Patient's Name: El formato HL7 XPN (Apellido^Nombre^Segundo) se mapea a la representación de valor DICOM PN (Person Name).
- OBR-18 → (0008,0050) Accession Number: Este es el campo de enlace crítico. El número de acceso asignado por el RIS identifica únicamente la orden y debe coincidir entre la entrada del worklist y las imágenes DICOM adquiridas. Las discrepancias causan "estudios huérfanos" que aparecen en PACS sin enlace correcto a la orden.
- OBR-4 → (0032,1060) Requested Procedure Description: La descripción legible del examen (ej. "TC Abdomen con Contraste") llena la entrada del worklist que el técnico ve en la pantalla de la modalidad.
- OBR-27 → (0040,0002) Scheduled Procedure Step Start Date: La fecha/hora programada indica a la modalidad cuándo se espera el examen, permitiendo el filtrado del worklist por ventana de tiempo.
Problemas Comunes de Integración
La mayoría de los problemas de integración del worklist de radiología provienen de un conjunto reducido de problemas recurrentes de calidad de datos. Los números de acceso faltantes (OBR-18 vacío) significan que el RIS no puede generar el tag DICOM Accession Number, llevando a estudios que no pueden enlazarse a órdenes. Los códigos de procedimiento vacíos o incorrectos (OBR-4) resultan en entradas de worklist sin descripción del examen, forzando a los técnicos a seleccionar manualmente el protocolo. Los IDs de paciente inconsistentes entre el HCE y el RIS causan fallos en la coincidencia de pacientes.
Usando Esta Herramienta para Análisis de Interfaces
Este Visor de Worklist de Radiología ayuda a analistas de integración e ingenieros clínicos a validar el flujo de datos de extremo a extremo analizando mensajes ORM crudos y mostrando exactamente cómo los campos HL7 se mapearían a atributos DICOM MWL. Al pegar capturas de ORM de producción (con PHI permaneciendo segura en el navegador), los equipos pueden verificar que los números de acceso estén presentes, los códigos de procedimiento estén correctamente codificados, la demografía del paciente coincida y las prioridades se extraigan adecuadamente — detectando problemas antes de que causen consultas fallidas de worklist o estudios huérfanos en sistemas PACS de producción.
Tres Flujos de Trabajo de un Analista de Interfaces
Un analista de RIS que prepara la conexión de una nueva modalidad pega un lote de órdenes sintéticas ORM^O01 capturadas de un motor de interfaces de pruebas y revisa la tabla del worklist en busca de huecos antes de que la modalidad consulte nada — un número de acceso vacío o un código de procedimiento en blanco aparece de inmediato como advertencia de validación, atrapando justo el defecto que de otro modo solo se manifestaría como un estudio huérfano tras la adquisición.
Un ingeniero clínico que investiga una queja de "estudio no encontrado" de un técnico pega la orden sintética en cuestión y abre Ver Detalles para ver el mapeo HL7-a-DICOM completo en paralelo — confirmando si el número de acceso que el RIS asignó en OBR-18 realmente coincide con lo que la modalidad espera recibir como (0008,0050), que es la causa más común de esa queja.
Un tercer escenario es una auditoría de codificación de prioridad entre sistemas emisores. Pegar un lote mixto de órdenes sintéticas de dos sistemas de origen distintos y filtrar por Stat revela si ambos sistemas codifican la urgencia de la misma forma en OBR-27/OBR-5 — una discrepancia aquí es cómo un examen genuinamente urgente pierde silenciosamente su marca Stat en el worklist.
Cuándo No Usar Esta Herramienta
Esto es una transformación local de mensaje a tabla, sin conexión en directo a un servicio DICOM Modality Worklist. No realiza una consulta DICOM C-FIND contra un SCP de MWL real, y no habla con un RIS, PACS o modalidad por ningún protocolo de red — solo muestra cómo se vería el mapeo HL7-a-DICOM de un mensaje pegado. También está limitada a mensajes de orden ORM^O01; no procesa los resultados ORU que llegan después, ni mensajes MDM/SIU de otras partes del flujo de radiología. Para validar una consulta de worklist real contra una modalidad en vivo, necesitas una herramienta de pruebas de conformidad DICOM conectada al SCP de MWL real, no este visor.
Campo HL7 → Tag DICOM MWL, en Breve
Una vista condensada de los mapeos que esta herramienta muestra con todo detalle para cada orden analizada:
| Campo HL7 | Tag DICOM MWL | Por qué importa |
|---|
| PID-3 | (0010,0020) Patient ID | Enlaza el estudio con el registro de paciente correcto |
| PID-5 | (0010,0010) Patient's Name | Se muestra en la consola de la modalidad durante la adquisición |
| OBR-18 | (0008,0050) Accession Number | El campo de enlace crítico entre la orden y el estudio adquirido |
| OBR-4 | (0032,1060) Requested Procedure Description | Nombre legible del examen que ve el técnico |
| OBR-27 | (0040,0002) Scheduled Procedure Step Start Date | Permite a la modalidad filtrar su worklist por ventana de tiempo |
Este patrón de mapeo sigue la transformación general RIS-a-MWL del perfil IHE Radiology Scheduled Workflow, referenciado en las fuentes más abajo.
Trabajar Junto a Otras Herramientas HL7
Antes de confiar en un mapeo de worklist, ayuda ver la orden en bruto completa. Pega el mismo ORM^O01 sintético en el Visor HL7 para inspeccionar cada segmento y campo con validación estructural, y usa el conversor HL7 a JSON si los datos de la orden necesitan alimentar un script o un sistema no HL7 río abajo. Leer primero el mensaje y luego mapearlo aquí mantiene honesto el mapeo DICOM sobre lo que realmente contenía la orden origen.
