Flujo completo HIS → RIS → Modalidad → PACS → HCE
Protocolo principal
HL7 v2 + DICOM 3.0
SWF usa
HL7 v2 para mensajes administrativos (ORM, ORU) y DICOM para imágenes y estado (C-STORE, MPPS, C-FIND). Son los "alfabetos"; SWF es la gramática que define cuándo y cómo usarlos.Actor clave: RIS
Coordinador central del flujo
El RIS actúa simultáneamente como Order Filler (recibe ORM), MWL Server (publica worklist DICOM), gestor de MPPS (cierra órdenes) y Result Creator (envía ORU). Es el único sistema que habla HL7 y DICOM.
Punto crítico
MPPS: el eslabón frágil
MPPS (Modality Performed Procedure Step) notifica el inicio y fin del estudio. Sin MPPS COMPLETED, el RIS nunca cierra la orden automáticamente. Es el fallo más frecuente en instalaciones reales y el que más impacta en facturación y TAT.
8 transacciones definidas por IHE-RAD
| Paso | Transacción IHE | Mensaje | Protocolo | Origen → Destino | Impacto si falla |
|---|---|---|---|---|---|
| 1 | RAD-1 — Order Placer | ORM^O01 | HL7 v2 | HIS → RIS | Todo manual, sin MWL |
| 2 | RAD-2 — Order Filler | ORM^O01 RSP | HL7 v2 | RIS → HIS | HIS no sabe si orden aceptada |
| 3 | RAD-5 — Query Worklist | C-FIND RQ | DICOM | Modalidad → MWL Server | Modalidad ciega, datos manuales |
| 4 | RAD-5 — Worklist Response | C-FIND RSP | DICOM | MWL Server → Modalidad | Sin estudios en lista |
| 5 | RAD-6 — MPPS In-Progress | N-CREATE | DICOM | Modalidad → PACS/RIS | RIS no sabe que estudio inició |
| 6 | RAD-8 — Store Images | C-STORE | DICOM | Modalidad → PACS | Sin imágenes en PACS, no hay diagnóstico |
| 7 | RAD-7 — MPPS Completed | N-SET COMPLETED | DICOM | Modalidad → PACS/RIS | Orden abierta indefinidamente |
| 8 | RAD-4 — Result Stored | ORU^R01 | HL7 v2 | RIS → HCE | Informe no llega al médico |
Escenario real: TC de tórax urgente
Caso clínico — Servicio de Urgencias, 03:42h
Paciente con disnea aguda — Protocolo TEP
1
El médico de urgencias solicita "TC Tórax con contraste — sospecha TEP" en el HIS. Se genera
ORM^O01 con Accession Number URG-2024-08821 y prioridad STAT.2
El RIS recibe el ORM, asigna el estudio al TC-1 de urgencias y publica la orden en la worklist DICOM. Prioridad máxima aparece al inicio de la lista.
3
El técnico en el TC pulsa "Actualizar lista". La modalidad hace
C-FIND y devuelve automáticamente los datos del paciente. El técnico selecciona el estudio y comienza, sin teclear ningún dato.4
Al iniciar la adquisición, el TC envía
MPPS IN-PROGRESS al PACS. El RIS marca el estudio como "En curso" y el dashboard de urgencias muestra el estado en tiempo real.5
Las 340 imágenes DICOM son enviadas mediante
C-STORE al PACS. Aparecen disponibles en la workstation del radiólogo de guardia antes de que el técnico termine.6
El TC envía
MPPS COMPLETED. El PACS notifica al RIS; la orden se cierra automáticamente. El estudio aparece en la worklist de lectura con prioridad STAT.7
El radiólogo dicta el informe. A los 8 minutos de la adquisición, el
ORU^R01 llega al HCE. El médico de urgencias recibe una alerta en su terminal: "TEP bilateral confirmado".Sin SWF — el mismo escenario
Tiempo de respuesta: 45-90 minutos
Sin SWF: el técnico teclea manualmente nombre, DNI y fecha de nacimiento. Error de un carácter → imágenes en PACS bajo paciente incorrecto. El radiólogo no encuentra el estudio. El médico llama por teléfono. TAT medio 4× mayor. Riesgo de error de identidad.
Modos de fallo más frecuentes en producción
Transacción RAD-1
PID vacío o malformado
RIS no puede crear MWL. Todo el flujo se rompe en el origen. TAT +300%. Técnicos entran datos manualmente.
Transacción RAD-5 · MWL
AETitle incorrecto
La modalidad hace C-FIND pero recibe 0 resultados. El técnico no ve ningún estudio aunque el RIS tenga órdenes.
Transacción RAD-7 · MPPS
MPPS COMPLETED no enviado
Órdenes abiertas indefinidamente en RIS. Facturación incorrecta. Dashboard de radiología muestra estudios "en curso" falsos.
Transacción RAD-8 · C-STORE
Imágenes sin Accession Number
Estudios en PACS sin vínculo con la orden. Radiólogo no puede relacionar imágenes con el paciente desde la worklist de lectura.
Transacción RAD-4 · ORU
Cola HL7 bloqueada
El informe existe en RIS pero no llega al HCE. El médico solicitante espera sin resultados. SLA de TAT incumplido.
Datos · Accession Number
AccNo duplicado
Error crítico de seguridad: imágenes de dos pacientes distintos bajo el mismo estudio. Riesgo de diagnóstico erróneo.
Flujo: creación y recuperación de Presentation States
El problema que resuelve
"En mi visor se ve diferente"
Sin CPI, cada visor aplica sus propios ajustes por defecto. Un radiólogo en el PACS ve la imagen con ventana pulmón; el médico en urgencias la abre con ventana hueso. La misma imagen, diagnósticos visuales distintos.
GSPS vs CSPS
Dos tipos de Presentation State
GSPS (Grayscale): para imágenes en escala de grises — TC, RM, RX. Guarda windowing. CSPS (Color): para imágenes a color — eco, medicina nuclear. Ambos son objetos DICOM almacenados en PACS.
Actores IHE-RAD
Image Display + Image Manager
El
Image Display (visor) crea y aplica Presentation States. El Image Manager (PACS) los almacena y sirve. La transacción RAD-23 define cómo el visor almacena el PS en el PACS para que cualquier otro visor lo recupere.Tipos de Presentation State DICOM
| Tipo PS | SOP Class | Uso clínico | Contenido |
|---|---|---|---|
| GSPS | 1.2.840.10008.5.1.4.1.1.11.1 | TC, RM, RX — escala de grises | Windowing, zoom, anotaciones, referencias de imagen |
| CSPS | 1.2.840.10008.5.1.4.1.1.11.2 | Eco, medicina nuclear, color | Lookup tables color, mismo conjunto que GSPS |
| BLENDING PS | 1.2.840.10008.5.1.4.1.1.11.4 | PET-TC fusion | Mezcla ponderada de dos series (PET + TC estructural) |
Transacción RAD-23 en detalle
| Paso | Operación | DIMSE | Descripción |
|---|---|---|---|
| 1 | Store Presentation State | C-STORE | El visor envía el PS al PACS como cualquier objeto DICOM. Se referencia al estudio por Study Instance UID. |
| 2 | Find Presentation State | C-FIND | Otro visor busca PS asociados a un Study Instance UID dado. |
| 3 | Retrieve Presentation State | C-MOVE / C-GET | El visor descarga el PS y lo aplica automáticamente al abrir el estudio. |
Caso clínico: nódulo pulmonar en seguimiento
Comité de tumores — revisión multidisciplinar
Seguimiento de nódulo pulmonar solitario a 6 meses
1
El radiólogo de tórax informa el TC inicial. Ajusta la ventana a W:1600/L:-650 (parénquima pulmonar óptimo), mide el nódulo con ROI circular (8.2mm, densidad -45 HU) y añade una flecha anotada.
2
Guarda un GSPS en el PACS con todos esos ajustes vinculados al Study Instance UID del estudio. Cualquier visor que abra el estudio recibirá la misma presentación automáticamente.
3
6 meses después, el oncólogo abre el estudio en su propio visor (diferente fabricante). Al cargar el estudio, el visor detecta el GSPS, lo aplica y muestra exactamente la misma ventana y anotación original.
4
En el comité de tumores, proyectan ambos estudios (basal y seguimiento) en el mismo monitor. Las ventanas son idénticas porque ambos usan el GSPS guardado. La comparación visual es directa y precisa.
Modos de fallo CPI
Configuración PACS
PACS no almacena Presentation States
Los PS se crean en el visor pero se pierden al cerrar la sesión. Nunca disponibles para otros visores.
Configuración Visor
Visor no aplica PS al abrir estudio
El PS existe en PACS pero el visor usa sus propios defaults. CPI inoperativo aunque técnicamente almacenado.
Calibración Monitor
Monitor sin calibración DICOM GSDF
El PS define la ventana correcta pero el monitor no está calibrado. La imagen sigue viéndose diferente físicamente.
Arquitectura: Nodo seguro + Repositorio de auditoría
ITI-19 — Node Authentication
TLS mutuo entre nodos
Cada sistema (HIS, RIS, PACS) tiene un certificado X.509. Antes de comunicarse, ambos lados verifican el certificado del otro. Imposible que un sistema no autorizado se conecte a la red clínica sin certificado válido.
ITI-20 — Audit Record Repository
Quién accedió a qué y cuándo
Cada acceso a datos PHI genera un mensaje de auditoría enviado al repositorio central vía
RFC 5424 Syslog sobre TLS. Los registros incluyen: usuario, acción, paciente, timestamp, IP, sistema origen. Inmutables.Cumplimiento legal
RGPD Art. 32 + HIPAA §164.312
ATNA cubre directamente el requisito de "medidas técnicas para garantizar la confidencialidad e integridad" del RGPD y el "Audit Control" del HIPAA. Sin ATNA, una auditoría regulatoria detectará incumplimiento.
Eventos que deben auditarse obligatoriamente
| Evento | DICOM Audit Type | Cuándo se emite | Campos obligatorios |
|---|---|---|---|
| User Login/Logout | UserAuthentication | Cada autenticación de usuario en cualquier sistema | UserID, NetworkAccessPoint, Outcome |
| Patient Query | Query | Búsqueda de paciente en HIS/RIS/PACS | UserID, PatientID, QueryType |
| PHI Access | PatientRecord | Apertura de historia clínica o estudio DICOM | UserID, PatientID, StudyUID, Action |
| DICOM C-STORE | DICOMInstancesTransferred | Almacenamiento de imágenes en PACS | PatientID, StudyUID, MediaType, Destination |
| Export / Print | Export | Cualquier exportación a CD, USB, red externa | UserID, Destination, SOPs exportados |
| Security Alert | SecurityAlert | Intento de acceso no autorizado, fallo TLS | AlertType, NetworkAccessPoint, Severity |
Caso real: investigación de acceso indebido a PHI
Incidente de privacidad — Persona pública hospitalizada
Auditoría reactiva: quién accedió al expediente sin autorización
1
La dirección del hospital recibe una denuncia: datos de un paciente público aparecieron en prensa. Ordenan auditoría. Sin ATNA: imposible saber quién accedió. Con ATNA: consulta al repositorio.
2
El equipo de seguridad filtra el Audit Repository por
PatientID = PAC-88821, rango de fechas y EventType = PatientRecord. Aparecen 47 accesos en las últimas 72 horas.3
23 accesos son del equipo médico asignado — justificados. 24 accesos son de una workstation del servicio de cardiología, fuera de guardia, a las 02:30h con el UserID de un residente no asignado al caso.
4
Los logs incluyen IP de origen, nombre del sistema (
WS-CARDIO-03), UserID y timestamp con precisión de milisegundos. El registro es sellado criptográficamente — no puede alterarse a posteriori.5
La evidencia ATNA se presenta ante la AEPD (Agencia Española de Protección de Datos). El hospital demuestra que tenía los controles en marcha y coopera con la investigación. Sanción reducida frente a un hospital sin trazabilidad.
Riesgos sin ATNA implementado
Seguridad
Comunicaciones en claro
Sin TLS mutuo (ITI-19), los mensajes HL7 y DICOM viajan sin cifrar por la red. Capturable con Wireshark desde cualquier punto de red interna.
Compliance RGPD
Sin trazabilidad de acceso
Art. 32 RGPD exige "medidas técnicas apropiadas". Sin audit log, multa de hasta 10M€ o 2% facturación en caso de brecha.
Forense
Imposible investigar incidentes
Si hay una fuga de datos, no hay evidencia de qué sistemas accedieron a qué. Imposible exculparse ante regulador.
Autenticación
Suplantación de nodo
Sin ITI-19, cualquier máquina en la red puede hacerse pasar por el PACS o RIS. Inyección de datos clínicos falsos posible.
Arquitectura: dos hospitales comparten estudios sin CD
¿Qué es el Affinity Domain?
La comunidad de confianza compartida
Un Affinity Domain es un grupo de instituciones que acuerdan compartir estudios a través de un XDS Registry común. Puede ser un sistema nacional de salud, una red regional, o un consorcio privado. Todas las instituciones deben confiar en el mismo repositorio de identidad de pacientes (PIX/PDQ).
KOS Manifest
El índice del estudio compartido
Un Key Object Selection (KOS) es un objeto DICOM especial que actúa como manifiesto: lista todas las series e instancias del estudio con su WADO URL. El Hospital B no recibe las imágenes automáticamente — recibe el KOS y descarga solo lo que necesita bajo demanda.
WADO vs DICOM tradicional
RESTful sobre HTTPS
El acceso cross-enterprise usa
WADO-RS (DICOMweb) sobre HTTPS en lugar del DICOM tradicional (C-MOVE). Más compatible con firewalls, proxies y arquitecturas cloud. Fundamental para implementaciones regionales y nacionales.Actores XDS-I y sus roles
| Actor | Rol | Transacción principal | Descripción |
|---|---|---|---|
| Imaging Document Source | PACS/VNA del hospital origen | RAD-69 WADO-RS Server | Almacena las imágenes y las sirve bajo demanda. No empuja activamente; espera solicitudes WADO. |
| Imaging Document Consumer | Visor/PACS del hospital destino | RAD-69 WADO-RS Client | Recupera imágenes del Source usando la WADO URL obtenida del Registry. |
| XDS.b Document Source | RIS del hospital origen | ITI-41 Provide & Register | Publica el KOS Manifest en el Registry con los metadatos del estudio y las WADO URLs. |
| XDS.b Document Consumer | HCE/RIS del hospital destino | ITI-43 Retrieve Document | Consulta el Registry para encontrar estudios de un paciente y obtener el KOS Manifest. |
| XDS.b Registry | Nodo central del Affinity Domain | ITI-42 Register Document | Índice central de documentos. No almacena imágenes, solo metadatos y WADO URLs. |
Caso clínico: traslado urgente con antecedentes críticos
Red hospitalaria regional — SUMMA 112 activa XDS-I
Accidente de tráfico — paciente trasladado desde hospital comarcal a hospital de referencia
1
El Hospital Comarcal realiza TC de trauma completo a las 11:42h. El RIS publica el KOS Manifest en el Registry regional con las WADO URLs del PACS comarcal.
2
A las 12:05h el paciente llega al Hospital Universitario de referencia. El médico de urgencias abre la HCE, busca al paciente y el sistema consulta automáticamente el Registry regional.
3
El Registry devuelve el KOS del TC de 11:42h. El visor del Hospital Universitario recupera las imágenes directamente del PACS comarcal vía WADO-RS. Disponibles en 90 segundos.
4
El traumatólogo ve el TC original sin re-irradiar al paciente. Identifica fractura de L2 que requiere cirugía. Sin XDS-I: el técnico del hospital comarcal grabaría un CD que llegaría en la ambulancia siguiente, si no se pierde.
Limitaciones y retos de implementación XDS-I
Identidad de paciente
PIX/PDQ sin implementar
Si el Hospital A usa NHC local y el B usa DNI, el mismo paciente tiene identidades distintas. El Registry no puede cruzar los estudios. Requiere Master Patient Index (MPI) compartido.
Disponibilidad
PACS origen inaccesible
Las imágenes se recuperan del PACS del hospital origen. Si está caído o con firewall restrictivo, el consumer no puede recuperar las imágenes aunque el KOS exista en el Registry.
Gobernanza
Acuerdos de Affinity Domain
XDS-I es técnico, pero requiere acuerdos legales y de privacidad entre instituciones. Sin convenio, ningún hospital compartirá estudios aunque tengan la tecnología.
Rendimiento
Latencia en estudios grandes
Un TC de tórax puede tener 2000 imágenes. Recuperar vía WADO-RS cross-network puede ser lento si no hay caché local. Implementar VNA regional con pre-fetch mejora la experiencia.
Flujo: creación y consumo de Key Image Note
El problema cuantificado
600 imágenes, 3 relevantes
Un TC de tórax de alta resolución produce 500-800 cortes. Un PET-TC puede tener 1400 imágenes. Sin KIN, un médico no radiólogo no puede localizar la imagen con la lesión. Con KIN, el visor salta directamente al corte marcado con descripción del hallazgo.
Tipos de marcado
Concept Name Codes
El KO incluye un código que clasifica por qué se marcó la imagen:
113013 = Best In Set (imagen más representativa), 113018 = For Referring Provider, 113036 = For Surgery. El visor puede filtrar por tipo de marcado.Relación con CPI y SWF
KIN + CPI = combo perfecto
KIN señala qué imágenes son relevantes. CPI garantiza que esas imágenes se vean igual en cualquier visor. Combinados, el médico receptor ve exactamente la imagen que eligió el radiólogo, con la misma ventana y anotaciones.
Estructura técnica del objeto KO DICOM
| Atributo DICOM | Tag | Valor ejemplo | Propósito |
|---|---|---|---|
| SOP Class UID | (0008,0016) | 1.2.840.10008.5.1.4.1.1.88.59 | Identifica el objeto como Key Object Selection Document |
| Study Instance UID | (0020,000D) | 1.2.345.6789… | Vincula el KO con el estudio padre |
| Concept Name Code | (0040,A043) | 113013 = Best In Set | Clasifica el tipo de marcado (para cirugía, para médico, imagen más representativa) |
| Key Object Desc. | (0070,0080) | "Nódulo LSD 8mm corte 234" | Descripción libre del hallazgo marcado, legible por el clínico receptor |
| Referenced SOP Sequence | (0008,1115) | SOP UID de cada imagen marcada | Lista exacta de las instancias DICOM seleccionadas por el radiólogo |
Caso clínico: comité multidisciplinar oncológico
Comité de Tumores — Hospital Universitario, jueves 08:30h
Tumor de pulmón: planificación quirúrgica con 5 especialistas
1
El radiólogo, antes del comité, marca 4 imágenes de 720 cortes de TC: el nódulo primario (Cr.187), la adenopatía hiliar (Cr.312), el contacto con pleura (Cr.445) y la imagen PET de mayor captación.
2
Genera un KO con Concept Name
113036 - For Surgery y descripción "T2aN1M0 - nódulo LSD, adp. hiliar ipsilateral, sin derrame". Lo almacena en PACS.3
En el comité, el cirujano torácico, el oncólogo y el neumólogo abren el estudio desde sus propios portátiles. Los tres visores detectan el KO y abren directamente en el corte 187 con la descripción del radiólogo.
4
El oncólogo hace click en "siguiente imagen clave" — va a Cr.312 (adenopatía). La discusión es ágil. En 12 minutos el comité toma la decisión de lobectomía superior derecha. Sin KIN: 40 minutos buscando los cortes relevantes en el proyector.
Impacto real: sin KIN vs con KIN
| Escenario | Sin KIN | Con KIN |
|---|---|---|
| Médico urgencias abre TC trauma (800 imgs) | Scroll manual: 3-5 minutos para encontrar la lesión | Abre directo en la imagen marcada: 10 segundos |
| Comité multidisciplinar (6 participantes) | 40 min. buscando cortes en proyector. Reunión se alarga. | 10-15 min. Todos ven las 4 imágenes clave en 1 click. |
| Residente de guardia revisa estudio nocturno | No sabe qué imagen es la importante. Puede pasar por alto hallazgo. | KO con descripción guía al residente directamente al hallazgo. |
| Traslado a otro centro (sin el radiólogo original) | El centro receptor no sabe qué imagen ver. Posible re-lectura innecesaria. | KO viaja con el estudio (XDS-I). El radiólogo receptor ve inmediatamente qué marcó el original. |
| Follow-up a 6 meses | Radiólogo busca el corte comparable manualmente. Riesgo de comparar imagen incorrecta. | KO previo indica el corte exacto. Comparativa milimétrica garantizada. |
Implementación Visor
Visor ignora KO objects
El KO existe en PACS pero el visor no lo detecta ni lo aplica. El médico sigue haciendo scroll manual. KIN inoperativo.
Workflow Radiólogo
Radiólogo no usa la función
KIN requiere que el radiólogo tome el tiempo de marcar las imágenes. Sin protocolo departamental de uso, queda infrautilizado.