Interoperabilidad en hospitales: cómo conectar sistemas médicos

La interoperabilidad en sistemas de información hospitalaria se evalúa con variables técnicas concretas: latencia de los mensajes, tasa de error de transformación, disponibilidad de las interfaces, trazabilidad de los eventos y porcentaje de datos que conserva su significado clínico. Si una de estas métricas falla, el problema no se limita al departamento de informática. Afecta al circuito asistencial.

Un HIS puede registrar el episodio del paciente. Un LIS puede gestionar las pruebas de laboratorio. Un RIS puede coordinar radiología. Un PACS puede almacenar y distribuir imágenes médicas. El reto consiste en que todos intercambien información estructurada, interpretable y segura. No basta con enviar documentos. El sistema receptor debe poder procesar los datos, relacionarlos con el paciente correcto y conservar su contexto clínico.

La integración de software médico exige separar tres problemas que suelen confundirse:

• Interoperabilidad sintáctica: los sistemas utilizan formatos y estructuras compatibles.
• Interoperabilidad semántica: los términos significan lo mismo en todas las plataformas.
• Interoperabilidad operativa: los datos llegan al sistema adecuado, en el momento adecuado y con trazabilidad suficiente.

La ausencia de una de estas capas produce un entorno aparentemente conectado, pero técnicamente frágil.

El ecosistema de datos clínicos: HIS, LIS, RIS y PACS

Un hospital no trabaja con una única aplicación. Trabaja con un conjunto de sistemas especializados, normalmente adquiridos en momentos distintos y con arquitecturas diferentes.

El HIS concentra la gestión hospitalaria general. Puede incluir admisión, agenda, episodios, camas, facturación, gestión de usuarios y datos administrativos. En muchos centros también actúa como punto principal de acceso al historial clínico electrónico.

El LIS gestiona el laboratorio. Recibe peticiones, identifica muestras, registra resultados, aplica reglas de validación y devuelve informes al sistema clínico. La comunicación no se limita al resultado final. También puede incluir estados de la petición, incidencias de la muestra, unidades de medida y rangos de referencia.

El RIS organiza los procesos de radiología. Gestiona solicitudes, citas, listas de trabajo, estados de exploración e informes radiológicos. Su función se relaciona directamente con el PACS, pero no es equivalente.

El PACS almacena y distribuye imágenes médicas. Radiografías, tomografías computarizadas, resonancias magnéticas y otras modalidades generan objetos de imagen que requieren metadatos, identificadores y reglas específicas de comunicación.

La conectividad entre sistemas hospitalarios debe respetar la función de cada plataforma. El HIS no sustituye al LIS. El RIS no sustituye al PACS. HL7 no desempeña la misma función que DICOM. Cada estándar resuelve una parte del circuito.

Qué ocurre cuando la integración es deficiente

La fragmentación produce fallos repetitivos. Algunos son visibles para el personal sanitario. Otros permanecen ocultos hasta que una incidencia de datos obliga a revisar todo el flujo.

Los problemas más habituales son los siguientes:

1. Duplicación de pacientes.

El mismo paciente aparece con identificadores diferentes en varios sistemas. La causa puede ser una mala sincronización de datos demográficos, reglas de coincidencia incompletas o ausencia de un índice maestro de pacientes.

2. Resultados sin contexto.

El resultado llega al HIS, pero pierde la relación con la petición, la muestra, la unidad de medida o el rango de referencia. El dato está presente. Su interpretación ya no es fiable.

3. Mensajes rechazados.

Una interfaz no acepta un mensaje porque falta un campo obligatorio, existe un formato incompatible o el sistema receptor aplica una validación distinta.

4. Imágenes no vinculadas al episodio correcto.

El estudio se almacena en el PACS, pero no aparece correctamente asociado al paciente, a la petición radiológica o al informe.

5. Estados desincronizados.

Un sistema marca una prueba como completada y otro la mantiene como pendiente. Esta discrepancia afecta a la planificación y a la supervisión del trabajo clínico.

6. Ausencia de trazabilidad.

El dato cambia durante una transformación, pero no existe un registro claro del sistema que lo modificó, la fecha del evento o la regla aplicada.

La tasa de error no debe calcularse únicamente sobre mensajes fallidos. También debe incluir transformaciones aceptadas técnicamente pero incorrectas desde el punto de vista clínico. Un mensaje que llega con un valor mal codificado no es un éxito de integración.

La interoperabilidad no consiste en que los sistemas estén conectados. Consiste en que intercambien datos utilizables, trazables y clínicamente equivalentes.

La convivencia de estándares: HL7 v2, CDA y FHIR

Los estándares HL7 permiten intercambiar información clínica y administrativa entre plataformas heterogéneas. En los hospitales modernos conviven varias generaciones y modalidades. La migración no suele producirse mediante una sustitución completa. Lo habitual es mantener sistemas existentes y añadir nuevas capas de integración.

HL7 v2: mensajería orientada a eventos

HL7 v2 utiliza mensajes de texto plano con delimitadores. La estructura se organiza mediante segmentos identificados con códigos de tres letras.

Entre los segmentos habituales se encuentran:

• MSH: cabecera del mensaje. Define el tipo de mensaje, el emisor, el receptor y otros parámetros de control.
• PID: identificación del paciente y datos demográficos.
• OBR: información de la solicitud o petición.
• OBX: observaciones y resultados clínicos.
• PV1: información del episodio o de la visita.

Este modelo resulta adecuado para eventos en tiempo real. Por ejemplo, una admisión, una petición de laboratorio, la recepción de un resultado o el cambio de estado de una prueba.

Su ventaja principal es la implantación extensa en sistemas hospitalarios. Su limitación aparece cuando cada fabricante interpreta los campos, las tablas y las reglas de forma diferente. Dos sistemas pueden utilizar HL7 v2 y seguir necesitando una transformación específica.

La interfaz debe controlar, como mínimo:

• versión del mensaje;
• estructura de los segmentos;
• campos obligatorios;
• tablas de valores;
• identificadores de paciente;
• unidades de medida;
• gestión de acentos y caracteres especiales;
• confirmaciones de recepción;
• reenvío de mensajes fallidos;
• correlación entre petición y resultado.

El procesamiento no termina cuando el receptor devuelve una confirmación técnica. La confirmación indica que el mensaje ha sido recibido o aceptado por una capa concreta. No garantiza que el dato haya quedado correctamente asociado al episodio clínico.

HL7 CDA: documentos clínicos estructurados

HL7 CDA R2 se orienta a documentos clínicos estructurados. Permite representar informes y documentos con una cabecera identificable y un cuerpo organizado. Su utilidad aparece cuando se necesita intercambiar información clínica con estructura documental y conservar el contexto del documento.

Un informe puede incluir autor, paciente, fecha, organización, sección clínica y contenido codificado. La estructura documental facilita el archivo y la consulta. Sin embargo, no todos los consumidores procesan del mismo modo el contenido interno. La integración debe determinar qué partes serán legibles por máquina y cuáles quedarán únicamente como texto.

CDA no debe utilizarse como sustituto universal de la mensajería de eventos. Una cosa es intercambiar un documento clínico. Otra es notificar en tiempo real que se ha solicitado una prueba o que un resultado está disponible.

FHIR: recursos y API REST

HL7 FHIR organiza la información mediante recursos clínicos y administrativos. La comunicación suele realizarse a través de API REST y formatos JSON o XML. Esta arquitectura facilita la integración con aplicaciones web, aplicaciones móviles, portales de paciente y servicios que necesitan consultar o actualizar datos de forma granular.

Entre sus componentes se encuentran recursos como:

• paciente;
• observación;
• diagnóstico;
• procedimiento;
• medicamento;
• organización;
• profesional;
• cita;
• episodio asistencial.

FHIR aporta una estructura más adecuada para arquitecturas basadas en servicios. También permite definir perfiles y extensiones para adaptar los recursos a las necesidades de una organización o de un dominio clínico.

Su adopción exige más que publicar una API. El hospital debe definir autenticación, autorización, registro de accesos, límites de consumo, versionado, gestión de errores y política de disponibilidad. Una API sin gobierno se convierte en otra fuente de inconsistencias.

FHIR tampoco elimina automáticamente los problemas del legado. Un HIS puede seguir generando mensajes HL7 v2 mientras una aplicación externa consume recursos FHIR. En ese escenario, el motor de integración transforma el mensaje de origen y construye el recurso de destino.

La decisión entre HL7 v2 y FHIR no debe formularse como una competición entre estándares. El diseño correcto depende del proceso. Un laboratorio puede mantener mensajería HL7 v2 para eventos internos y exponer resultados mediante FHIR para aplicaciones externas. La arquitectura híbrida es frecuente y técnicamente válida.

Gestión de imagen médica: DICOM y DICOMweb

DICOM gestiona la adquisición, el almacenamiento y la comunicación de imágenes médicas. Se utiliza entre modalidades de imagen, estaciones de trabajo, RIS y PACS.

Su alcance es distinto al de HL7. DICOM describe objetos de imagen y sus metadatos. HL7 comunica eventos, solicitudes, resultados e información clínica o administrativa. Ambos estándares pueden participar en el mismo flujo, pero no son intercambiables.

Un circuito de radiología puede incluir:

1. El HIS registra al paciente y el episodio.

2. El RIS recibe o genera la solicitud de exploración.

3. La modalidad obtiene la lista de trabajo.

4. El equipo realiza la adquisición.

5. Las imágenes se envían al PACS mediante DICOM.

6. El radiólogo revisa el estudio.

7. El informe se registra en el RIS.

8. El informe y el estado del estudio se comunican al HIS.

9. Una aplicación clínica consulta las imágenes y el informe.

Cada paso tiene una posible fuente de error. El identificador del paciente puede no coincidir. La modalidad puede recibir una petición desactualizada. El estudio puede llegar al PACS sin vinculación correcta. El informe puede completar el circuito administrativo, pero no reflejar el estado técnico de la imagen.

Lista de trabajo y consistencia de identificadores

La lista de trabajo de modalidad reduce la introducción manual de datos. El equipo de imagen recibe información procedente del RIS y utiliza esos datos durante la adquisición. El beneficio depende de que la fuente de origen sea fiable.

Los identificadores deben mantenerse de forma consistente en todo el circuito:

• identificador interno del paciente;
• identificador de la solicitud;
• identificador del estudio;
• identificador de la serie;
• fecha y hora de adquisición;
• modalidad;
• institución responsable.

Una corrección manual posterior puede resolver un caso aislado. No corrige la causa del problema. Si el hospital detecta múltiples estudios mal asociados, debe revisar la generación de la lista de trabajo, las reglas de reconciliación y las políticas de modificación de metadatos.

DICOMweb: acceso mediante HTTP

DICOMweb incorpora servicios basados en HTTP para consultar, almacenar y recuperar objetos DICOM. Entre sus componentes principales se encuentran:

• QIDO-RS: consulta de estudios, series e instancias.
• WADO-RS: recuperación de objetos DICOM.
• STOW-RS: almacenamiento de objetos DICOM.

Esta arquitectura facilita la integración con aplicaciones web y servicios que no utilizan los mecanismos clásicos de comunicación DICOM. También permite diseñar flujos de acceso más próximos a los modelos actuales de API.

La implantación requiere controlar el rendimiento del almacenamiento, la latencia de consulta, el tamaño de los objetos, la compresión, la autenticación y la gestión de permisos. El hecho de que una imagen esté disponible mediante HTTP no implica que el acceso sea seguro ni que la aplicación respete el contexto asistencial.

La seguridad debe cubrir tanto los metadatos como el contenido de las imágenes. Las cabeceras DICOM pueden contener información identificativa. La anonimización no consiste únicamente en ocultar el nombre del paciente. Debe analizarse el conjunto de atributos y el flujo de exportación.

El reto de la interoperabilidad semántica

La interoperabilidad sintáctica responde a una pregunta básica: ¿puede el sistema leer el mensaje? La interoperabilidad semántica plantea una pregunta más exigente: ¿interpreta el sistema el dato con el mismo significado clínico?

Un resultado de laboratorio puede llegar con un valor numérico correcto y una unidad ausente. También puede utilizar un código local que el receptor no reconoce. En ambos casos, el mensaje puede ser válido desde el punto de vista estructural. Su utilidad clínica es limitada.

SNOMED CT y LOINC

SNOMED CT se utiliza para representar conceptos clínicos, hallazgos, diagnósticos y procedimientos con una terminología estructurada. LOINC se orienta especialmente a pruebas, observaciones y mediciones de laboratorio.

El uso de terminologías de referencia permite reducir la dependencia de textos locales. Un hospital puede denominar una prueba de una forma y otro emplear una etiqueta distinta. El código común permite relacionar ambos conceptos si la correspondencia está bien definida.

La terminología no debe incorporarse al final del proyecto como una tarea de limpieza. Debe formar parte del diseño de datos. La organización debe definir:

• catálogo maestro de conceptos;
• códigos permitidos por proceso;
• equivalencias entre códigos locales y de referencia;
• unidades de medida;
• valores cualitativos;
• estados de resultado;
• reglas para conceptos obsoletos;
• responsable de mantenimiento;
• control de versiones.

El mapeo entre terminologías requiere revisión clínica. No puede delegarse por completo en una regla automática. Dos conceptos que parecen similares pueden diferir en muestra, método, lateralidad, contexto o población.

Unidades y rangos de referencia

La unidad de medida forma parte del significado de un resultado. El valor numérico no debe transmitirse de forma aislada. El sistema receptor necesita conocer la unidad, el tipo de prueba y, cuando proceda, el rango de referencia.

Los rangos pueden variar según el método, el laboratorio, la edad o las condiciones del paciente. La integración no debe sustituir el rango original por un valor genérico. Debe conservar el contexto en el que el resultado fue validado.

El mismo control se aplica a los valores cualitativos. Términos como positivo, negativo, detectado, no detectado, indeterminado o pendiente no siempre son equivalentes. El catálogo debe definir la representación aceptada y su interpretación.

Unificación de historiales clínicos

La unificación de historiales clínicos no consiste en copiar registros de una aplicación a otra. Requiere resolver identidad, procedencia y contexto.

Un expediente consolidado debe permitir responder a estas preguntas:

1. ¿A qué paciente pertenece el dato?

2. ¿Qué sistema lo originó?

3. ¿Cuándo se generó?

4. ¿Quién lo validó?

5. ¿Qué transformación sufrió?

6. ¿Qué unidad y terminología utiliza?

7. ¿Puede modificarse o solo consultarse?

8. ¿Qué aplicación tiene permiso para mostrarlo?

La identificación maestra del paciente es uno de los componentes críticos. Si existe una coincidencia incorrecta, el sistema puede vincular información de dos personas distintas. La deduplicación automática debe trabajar con reglas controladas y mecanismos de revisión. No debe basarse únicamente en nombre y fecha de nacimiento.

Motores de integración: el middleware hospitalario

Un motor de integración actúa como intermediario entre sistemas. Recibe mensajes, aplica reglas, transforma formatos, enruta información y registra el resultado. En entornos hospitalarios se utilizan soluciones como Mirth Connect y otras plataformas de middleware.

El motor permite evitar una red de conexiones directas entre cada aplicación. En una arquitectura punto a punto, cada nuevo sistema exige nuevas interfaces. La complejidad crece con rapidez y el mantenimiento se vuelve difícil de controlar.

El middleware centraliza funciones como:

• recepción de mensajes;
• validación estructural;
• transformación de campos;
• conversión de terminologías;
• enrutamiento por tipo de evento;
• filtrado de información;
• control de errores;
• reenvío;
• auditoría;
• monitorización.

No obstante, un motor de integración no corrige por sí solo un diseño deficiente. Puede automatizar una mala regla con mucha eficiencia. Antes de desplegarlo, el hospital debe documentar los flujos y definir el comportamiento esperado.

Secuencia de integración recomendada

La integración de software médico debe ejecutarse por fases. Un orden razonable es el siguiente:

1. Inventariar los sistemas y las interfaces existentes.

El inventario debe incluir HIS, LIS, RIS, PACS, farmacia, receta electrónica, identidad, analítica y aplicaciones externas. También debe registrar versiones, protocolos, responsables y dependencias.

2. Definir el evento clínico o administrativo.

La interfaz debe partir de un caso concreto: alta de paciente, solicitud de laboratorio, resultado validado, creación de cita o disponibilidad de informe.

3. Identificar la fuente de autoridad.

Cada dato debe tener un sistema responsable. El HIS puede ser la fuente de determinados datos demográficos. El LIS puede ser la fuente del resultado validado. El PACS puede ser la fuente de los objetos de imagen.

4. Seleccionar el estándar y el patrón de comunicación.

HL7 v2 puede resolver la mensajería de eventos. FHIR puede servir para exponer recursos mediante API. DICOM puede transportar imágenes y metadatos de imagen. CDA puede representar documentos clínicos estructurados.

5. Definir el modelo semántico.

El equipo debe establecer códigos, unidades, estados, terminologías y reglas de equivalencia. Aquí se determina si se utilizarán SNOMED CT, LOINC u otros catálogos autorizados.

6. Diseñar las reglas de transformación.

Toda transformación debe ser explícita. El sistema debe documentar qué campo de origen alimenta cada campo de destino y qué ocurre cuando el valor no existe.

7. Configurar la gestión de errores.

Un mensaje fallido debe quedar en una cola identificable. La interfaz debe conservar la causa del rechazo, permitir la corrección controlada y evitar duplicados durante el reenvío.

8. Probar con datos representativos.

Las pruebas deben incluir nombres con caracteres especiales, pacientes duplicados, cambios de identidad, resultados sin rango, valores nulos, peticiones canceladas y mensajes fuera de secuencia.

9. Validar el flujo con usuarios clínicos.

La comprobación técnica no es suficiente. Un profesional debe confirmar que el dato aparece en el episodio correcto, con el significado y la trazabilidad esperados.

10. Monitorizar después de la puesta en producción.

La supervisión debe cubrir latencia, disponibilidad, errores, mensajes pendientes, tiempos de reenvío y discrepancias entre sistemas.

La documentación debe mantenerse después del despliegue. Una interfaz sin propietario técnico y funcional pierde fiabilidad con cada cambio de versión.

Qué debe medir el hospital

La monitorización debe combinar indicadores de infraestructura e indicadores de calidad de datos.

Entre los primeros se encuentran:

• disponibilidad del motor;
• latencia entre emisión y recepción;
• número de mensajes en cola;
• tiempo medio de recuperación;
• consumo de recursos;
• capacidad de almacenamiento de logs;
• tasa de indisponibilidad de los sistemas dependientes.

Entre los segundos:

• mensajes rechazados;
• transformaciones incompletas;
• pacientes duplicados;
• resultados sin unidad;
• estudios sin asociación correcta;
• eventos fuera de secuencia;
• registros sin terminología válida;
• incidencias de reconciliación manual.

Una interfaz puede presentar una disponibilidad elevada y, aun así, entregar datos clínicamente incompletos. Por eso la tasa de éxito técnico debe analizarse junto con la calidad semántica.

Seguridad, trazabilidad y gobierno del dato

La interoperabilidad amplía el número de sistemas que acceden a la información clínica. También aumenta la superficie de exposición. Cada API, motor, estación de trabajo, repositorio y conexión externa debe formar parte del modelo de seguridad.

La arquitectura debe aplicar controles de identidad, autorización y auditoría. No todos los sistemas necesitan acceso a todos los datos. Una aplicación de agenda no debería disponer de los mismos permisos que una plataforma de consulta clínica.

El registro de auditoría debe permitir reconstruir el recorrido del dato:

• sistema que lo generó;
• sistema que lo recibió;
• fecha y hora;
• usuario o proceso técnico;
• transformación aplicada;
• resultado de la operación;
• correcciones posteriores;
• accesos realizados.

La trazabilidad es especialmente relevante cuando el dato se utiliza en procesos clínicos, administrativos o de facturación. Sin un registro fiable, la organización no puede distinguir entre un error de origen, un fallo de transmisión y una modificación posterior.

La seguridad del canal también debe separarse de la seguridad de la aplicación. HTTPS protege la comunicación de una API, pero no define por sí mismo quién puede consultar un recurso. Del mismo modo, una VPN no resuelve una autorización excesiva dentro del sistema.

La protección de datos médicos requiere segmentación, mínimo privilegio, gestión de credenciales, revisión de permisos y respuesta ante incidentes. El middleware debe evitar almacenar más información de la necesaria en colas, trazas y registros de depuración. Los logs pueden contener datos identificativos si no se configuran correctamente.

Errores habituales en proyectos de interoperabilidad

Los fallos de diseño se repiten. La mayoría no procede de una limitación del estándar, sino de una definición incompleta del proceso.

Tratar el PDF como integración estructurada

Un PDF facilita la lectura humana. No garantiza que el sistema receptor pueda extraer cada dato de manera fiable. Si el objetivo es automatizar validaciones, búsquedas, alertas o análisis, se necesitan datos estructurados.

El documento puede complementar el intercambio estructurado. No debe sustituirlo cuando el proceso exige procesamiento automático.

Conectar sistemas sin definir la propiedad del dato

Si dos aplicaciones pueden modificar el mismo campo sin reglas de prioridad, el resultado depende del orden de llegada. La organización debe establecer cuál es la fuente de autoridad y qué sistema puede actualizar cada elemento.

Convertir códigos sin validación clínica

Una tabla automática puede asociar códigos parecidos, pero no necesariamente equivalentes. La transformación debe revisarse con responsables clínicos y de información sanitaria.

Ignorar los mensajes fuera de secuencia

Los sistemas distribuidos no siempre reciben los eventos en el orden esperado. Puede llegar un resultado antes de la actualización de la petición o una cancelación después de una validación. La interfaz debe controlar estas situaciones.

Usar una única prueba de éxito

Que el paciente aparezca en el sistema no demuestra que la integración funcione. La prueba debe cubrir el ciclo completo: creación, modificación, cancelación, validación, consulta, error y recuperación.

Confundir disponibilidad con calidad

Un servicio puede estar disponible y transmitir datos incorrectos. La supervisión debe medir tanto el estado del sistema como la integridad del contenido.

Diseñar sin estrategia de evolución

HL7 v2, CDA, FHIR y DICOM pueden coexistir durante años. El hospital necesita una estrategia de versiones, compatibilidad y retirada progresiva de interfaces. La migración completa de un estándar a otro no debe darse por supuesta.

Cómo elegir la arquitectura de integración

La arquitectura debe responder al volumen, la criticidad y la diversidad de los flujos. No existe una única configuración válida para todos los hospitales.

Un centro con sistemas heredados y numerosos proveedores puede necesitar un motor de integración centralizado. Una organización con aplicaciones nuevas puede incorporar API FHIR para determinados servicios. Un entorno intensivo en imagen requerirá una arquitectura DICOM y DICOMweb bien dimensionada. En todos los casos, la interoperabilidad semántica seguirá siendo necesaria.

La evaluación técnica debe considerar:

• número de sistemas conectados;
• volumen de mensajes;
• tamaño y frecuencia de los objetos DICOM;
• necesidad de tiempo real;
• tolerancia a retrasos;
• criticidad clínica;
• capacidad de reintento;
• requisitos de auditoría;
• gestión de terminologías;
• escalabilidad horizontal;
• dependencia de proveedores;
• mantenimiento de versiones.

La escalabilidad no es solo capacidad de procesamiento. También incluye la posibilidad de añadir una nueva modalidad, un nuevo laboratorio o una aplicación externa sin rediseñar toda la red de interfaces.

Una solución puede funcionar con cinco sistemas y fallar cuando se incorporan veinte. La arquitectura debe evaluarse con el escenario de crecimiento previsto y con los flujos de mayor carga.

La interoperabilidad como disciplina operativa

La conexión inicial es solo una fase. El rendimiento real depende de la operación diaria. Las terminologías cambian. Los sistemas se actualizan. Las modalidades incorporan nuevas versiones. Los perfiles FHIR evolucionan. Las reglas de laboratorio se modifican. Cada cambio puede afectar a una interfaz existente.

El hospital necesita un modelo de gobierno con funciones diferenciadas:

• responsable del proceso clínico;
• propietario funcional de los datos;
• administrador del sistema de origen;
• responsable del sistema receptor;
• equipo de integración;
• responsable de seguridad;
• responsable de terminologías;
• equipo de soporte y continuidad.

Las incidencias deben clasificarse por impacto. Un mensaje administrativo retrasado no tiene la misma prioridad que un resultado crítico que no aparece en el episodio correcto. La gestión de colas debe reflejar esa diferencia.

También conviene establecer ventanas de mantenimiento, pruebas de regresión y procedimientos de reversión. Una actualización no debe desplegarse sin comprobar los mensajes generados por las versiones anteriores.

La documentación operativa debe incluir ejemplos de mensajes, reglas de transformación, códigos de error, propietarios y procedimiento de recuperación. Sin esta información, el conocimiento queda concentrado en personas concretas y la continuidad depende de su disponibilidad.

La interoperabilidad en sistemas de información hospitalaria es, por tanto, una combinación de estándares, arquitectura, terminología, seguridad y operación. HL7 v2 mantiene su utilidad en la mensajería hospitalaria. FHIR aporta una vía estructurada para API y aplicaciones modernas. DICOM gestiona la imagen médica. DICOMweb extiende ese acceso hacia servicios basados en HTTP. SNOMED CT y LOINC ayudan a conservar el significado clínico. El middleware coordina el conjunto.

El criterio final no debe ser cuántos sistemas están conectados. Debe ser si el dato llega al destino correcto, conserva su significado, puede rastrearse y se mantiene disponible con una latencia compatible con el proceso clínico.

Una arquitectura interoperable no elimina la complejidad hospitalaria. La hace visible, medible y gestionable. Esa es la condición mínima para optimizarla.