Integración PACS-RIS-HIS sin dolor: glosario práctico

"¿Por qué este estudio no aparece en el visor?", "¿Por qué hay dos pacientes con el mismo nombre y distinto DNI?", "¿Por qué el técnico tuvo que escribir los datos del paciente a mano en el tomógrafo?". Las tres preguntas se responden con la misma palabra: integración. PACS, RIS y HIS son sistemas separados, hablan idiomas distintos, y la calidad del workflow radiológico depende de qué tan bien estén enchufados entre sí. Esta guía es el glosario y mapa que conviene tener cerca cuando se está armando o auditando una integración.

Los tres sistemas en una línea cada uno

• HIS (Hospital Information System) — el sistema central del hospital o sanatorio. Maneja al paciente como entidad clínica completa: admisión, historia clínica, médicos, internación, facturación, farmacia.
• RIS (Radiology Information System) — el workflow específico de radiología: agenda de turnos, lista de trabajo del técnico, asignación de informes, estado del estudio, plantillas administrativas.
• PACS (Picture Archiving and Communication System) — el archivo y distribución de las imágenes DICOM. Almacenamiento masivo, búsqueda, distribución a visores y otros sistemas.

Conceptualmente: el HIS sabe "este paciente existe y se llama X"; el RIS sabe "este paciente tiene una orden de TC de tórax el martes a las 10"; el PACS sabe "estas son las 1.500 imágenes que se generaron". Si están integrados, los tres comparten el mismo paciente. Si no, tenés tres versiones del paciente y problemas.

Mapa del flujo ideal

Un caso típico, paso a paso:

1. El médico solicita una TC de tórax desde el HIS o el RIS.
2. El RIS crea una orden con un identificador único llamado accession number.
3. El paciente se presenta a turno. La recepción lo identifica contra el HIS y confirma la orden en el RIS.
4. El técnico arranca el tomógrafo y consulta la Modality Worklist (MWL): una lista de las órdenes del día que el equipo descarga del RIS. Selecciona al paciente con un click; los datos del paciente, la indicación y el protocolo se cargan automáticamente.
5. El tomógrafo adquiere el estudio.
6. El tomógrafo manda las imágenes al PACS con C-STORE (DIMSE — ver la guía sobre DICOMweb vs DIMSE). El accession number viaja en el header DICOM y enlaza la imagen con la orden.
7. El RIS recibe notificación de que el estudio ya está en el PACS y cambia el estado a "para informar".
8. El radiólogo abre el visor, busca por worklist en el RIS, hace doble click — el visor le pide las imágenes al PACS y las muestra.
9. El radiólogo escribe el informe (idealmente con plantilla — ver la guía de plantillas). Lo firma.
10. El RIS publica el informe al HIS, queda accesible al médico solicitante.

Cada paso de 4 a 10 es un mensaje entre sistemas. Si alguno se rompe, el estudio se atasca: ahí entra el equipo de IT del centro.

Glosario: los protocolos y mensajes que viajan

HL7 v2

El "lenguaje" administrativo dominante. Mensajes de texto con segmentos delimitados por pipes (|). Los tipos que cualquier integrador conoce:

• ADT (Admission, Discharge, Transfer) — alta, baja, traslado de paciente. ADT^A04 (registro), ADT^A08 (actualización de datos), ADT^A03 (alta).
• ORM (Order Message) — nueva orden, modificación o cancelación. Es el mensaje que el RIS le pide al PACS o al tomógrafo para crear una nueva orden de estudio.
• ORU (Observation Result) — resultado del estudio (texto del informe). Es lo que el RIS le manda al HIS cuando el radiólogo firma.
• SIU (Scheduling Information Unsolicited) — turnos y agenda.

HL7 v2 es ubícuo y feo. Es el protocolo del intercambio hospitalario desde los 90. Sigue siendo el estándar de facto, aunque está siendo desplazado lentamente por FHIR.

FHIR (Fast Healthcare Interoperability Resources)

El reemplazo moderno de HL7 v2. REST sobre HTTPS con recursos en JSON. Mucho más cómodo para programar. Las versiones recientes (R4, R5) están maduras y los hospitales nuevos lo adoptan. Convive con HL7 v2 durante años porque los sistemas viejos no migran rápido. Equivalencias rápidas: Patient, Encounter, ServiceRequest (ex-ORM), DiagnosticReport (ex-ORU), ImagingStudy.

Modality Worklist (MWL)

Servicio DIMSE específico que le permite al tomógrafo, resonador o ecógrafo descargar la lista de pacientes del día desde el RIS. Sin MWL, el técnico escribe el nombre del paciente a mano en el equipo — fuente garantizada de errores tipográficos y de DNIs mal cargados. Con MWL, el técnico selecciona de una lista y todo se rellena solo.

Si tu centro todavía tiene técnicos cargando datos a mano en el equipo, lo primero a integrar es MWL. El retorno de inversión es inmediato: menos errores, menos tiempo por paciente, accession numbers consistentes desde el origen.

MPPS (Modality Performed Procedure Step)

El "callback" del equipo al RIS confirmando que el estudio se ejecutó. Útil para que el RIS marque el estado "en adquisición → adquisición completa" sin que alguien apriete un botón manualmente.

UPS-RS (Unified Procedure Step)

La versión moderna de MWL+MPPS, sobre DICOMweb. Aún en adopción.

IHE (Integrating the Healthcare Enterprise)

No es un protocolo sino una organización que define perfiles de integración — recetas que dicen "para hacer X workflow, usá los protocolos A, B y C de esta manera específica". Los perfiles más relevantes:

• SWF (Scheduled Workflow) — el flujo radiológico completo desde orden hasta informe.
• PIR (Patient Information Reconciliation) — manejo de cambios de identidad de paciente.
• PDQ (Patient Demographics Query) — buscar paciente en el HIS desde el RIS.
• XDS (Cross-Enterprise Document Sharing) — compartir documentos clínicos entre instituciones.

Si un vendor dice "soporta perfil SWF de IHE", eso es información concreta y verificable. "Soporta integración" no es información.

Los problemas reales del día a día

Paciente duplicado

El paciente Juan Pérez se cargó dos veces en el HIS con DNIs distintos (uno con error de tipeo). El RIS recibe dos versiones, los estudios de uno no aparecen al buscar por el otro. La causa raíz es identificador único: tiene que haber una autoridad maestra de identidad de paciente (típicamente el HIS) y todos los demás sistemas deben referenciarla. Cuando aparece un duplicado, hay que mergeear (perfil PIR de IHE).

Estudio sin orden

El equipo mandó imágenes al PACS pero no hay accession number coincidente en el RIS. Causas comunes: el técnico no usó MWL y tipeó datos a mano; o el RIS no había generado la orden todavía cuando el técnico inició la adquisición. El estudio queda "huérfano" en el PACS y debe reconciliarse manualmente.

Informe sin estudio

Más raro pero también pasa: el RIS publica un informe al HIS pero el HIS no encuentra el estudio referenciado porque el accession number no se propagó bien. El médico ve el informe sin las imágenes accesibles.

Datos del paciente desincronizados

El paciente se casó y cambió apellido. El HIS se actualizó pero los estudios viejos en el PACS siguen con el apellido anterior. Al buscar por el nuevo apellido no aparecen. Solución: el HIS debe emitir un ADT^A08 que el PACS escuche y propague.

Estado del estudio inconsistente

El estudio figura como "para informar" pero ya está informado. O viceversa. Indica que los mensajes MPPS u ORU no llegaron o no se procesaron. Suele resolverse con un endpoint de "forzar resync" del estado, que conviene tener disponible.

Arquitecturas posibles (de menor a mayor)

Todo en uno (centros chicos)

Un único producto que combina RIS + PACS. Más fácil de integrar (todo es interno), menos flexible para crecer. Buenas opciones existen para 1-3 radiólogos. El "HIS" puede ser una agenda simple si el centro no es hospital.

RIS + PACS separados, mismo proveedor

Productos del mismo vendor que se integran de fábrica. Equilibrio razonable entre flexibilidad y simplicidad. La integración con HIS de otro vendor sigue requiriendo trabajo.

RIS + PACS + HIS de proveedores distintos

Lo normal en hospitales medianos y grandes. Cada uno elegido por su fortaleza. Requiere un motor de integración (Mirth Connect, Iguana, Rhapsody) que traduce HL7 v2/FHIR entre sistemas. Es donde vive la complejidad real. Es también donde una integración bien hecha o mal hecha define la productividad del hospital.

Arquitectura multi-centro / cloud

Un mismo PACS sirve a varios centros físicos. Cada centro puede tener su RIS local, todos vuelcan al PACS central. Requiere DICOMweb sobre HTTPS, tokens, y manejo cuidadoso del scope de visibilidad (que cada médico vea solo lo suyo). Las arquitecturas modernas se diseñan así desde el día uno.

Cómo elegir un partner de integración

1. Pedí experiencia documentada. Cuántos centros de tamaño similar al tuyo integró ese partner. Hablá con dos referencias no sugeridas por el vendor.
2. Identificá quién es responsable de qué. En una integración intervienen RIS, PACS, HIS, integrador, motor de integración, equipos de imagen, red, firewall. Cuando algo falla, "no es mi sistema" es la respuesta más común. Definí dueño por interface, no por sistema.
3. Mapeá los mensajes desde el día uno. Documentá qué HL7/FHIR/DICOM viaja por cada conexión. Sin este documento, los problemas que aparezcan en 6 meses se vuelven irresolubles.
4. Pediá entorno de testing. Una integración que solo se prueba en producción es una integración que falla en producción.
5. SLA con sentido. No es lo mismo "soporte 24x7" que "respuesta en 2h, resolución en 8h". La diferencia se paga, y en una falla de integración un sábado se siente.
6. Plan de salida. ¿Qué pasa si querés cambiar de PACS en 5 años? ¿Te entregan los estudios en formato DICOM estándar exportable?

Cómo se posiciona IMARAD en este ecosistema

Conclusión

Integración no es un punto final — es un proceso continuo. Los sistemas cambian, los pacientes se duplican, los formatos evolucionan (HL7 v2 → FHIR), las modalidades nuevas traen sus propias rarezas. Un workflow radiológico funciona bien cuando las interfaces están documentadas, los responsables son claros y existe un equipo (interno o partner) que las mantiene activamente.

Si estás arrancando un proyecto de integración, lo más importante a hacer en las primeras dos semanas es: dibujar el flujo del paciente desde la solicitud hasta el informe firmado, identificar qué sistema es dueño de qué dato, y poner en blanco sobre negro qué mensajes (HL7, DICOM, FHIR) viajan en cada paso. El resto es ejecución sobre ese mapa.