Un hospital puede disponer de un sistema de información hospitalaria (HIS), una historia clínica electrónica (HCE, o EHR por sus siglas en inglés), un sistema de citas, herramientas de comunicación, plataformas de analítica y diferentes aplicaciones administrativas. Cada uno puede funcionar correctamente. El problema aparece cuando necesitan trabajar juntos.
Una cancelación registrada en la agenda puede no llegar al equipo responsable de recuperar capacidad. Una comunicación enviada al paciente puede no quedar relacionada con el proceso que la originó. Un indicador operativo puede requerir exportaciones manuales de varios sistemas para poder calcularse. En estos casos, el problema no es necesariamente la falta de tecnología. Es la falta de continuidad entre procesos.
La interoperabilidad sanitaria permite abordar esa fragmentación, pero no debería confundirse con trasladar toda la información clínica a una nueva plataforma. El objetivo no es conectar sistemas por conectarlos. Es conseguir que un proceso continúe correctamente cuando atraviesa diferentes sistemas.
El HIS/EHR debe continuar siendo el sistema de referencia
Cuando un hospital incorpora nuevas herramientas digitales, resulta tentador crear una base de datos central que reúna toda la información necesaria. En ocasiones puede existir una justificación técnica para mantener determinados datos en una plataforma de integración. Pero eso no significa que deba crearse otro sistema responsable de la información clínica.
El HIS/EHR debe continuar gobernando los datos y procesos que le corresponden. El sistema de agenda debe mantener la información autorizada sobre disponibilidad, confirmaciones y modificaciones de citas. Las herramientas de comunicación pueden encargarse de enviar mensajes, pero no deberían convertirse en una fuente independiente sobre el estado real de una cita.
Las plataformas analíticas pueden combinar indicadores sin convertirse en otro sistema operativo. Este principio ayuda a mantener responsabilidades claras. También reduce la necesidad de reconciliar información entre múltiples aplicaciones.
Una arquitectura bien diseñada puede incluir diferentes tecnologías sin obligar al hospital a sustituir las plataformas que ya utiliza.
Interoperabilidad no significa solamente intercambiar datos
Dos sistemas pueden intercambiar información y seguir sin colaborar correctamente. Por ejemplo, una aplicación puede recibir una lista de citas desde el HIS. Eso demuestra que existe una conexión.
Pero si el paciente cancela una cita desde esa aplicación y el cambio no vuelve al sistema de agenda, el proceso permanece incompleto. La información circula en una dirección, mientras la operación necesita coordinación en ambas. Por eso conviene distinguir tres niveles.
- El primero es el intercambio técnico: un sistema puede enviar y recibir datos.
- El segundo es la interpretación: ambos sistemas comprenden correctamente el significado de esos datos.
- El tercero es la continuidad operativa: la información permite completar una acción sin introducir tareas manuales innecesarias.
En transformación digital sanitaria, este último nivel es el que suele generar mayor valor.
Qué aporta HL7 FHIR y qué no resuelve por sí solo
FHIR, desarrollado por HL7, es un estándar para representar e intercambiar información sanitaria electrónicamente. Permite trabajar con recursos estructurados relacionados con pacientes, citas, observaciones, procedimientos y otros elementos del entorno sanitario. Su utilización puede facilitar integraciones entre plataformas que implementan versiones y perfiles compatibles.
Pero utilizar FHIR no garantiza automáticamente que dos sistemas funcionen juntos. Pueden existir diferencias entre versiones, perfiles, terminologías, permisos y funciones soportadas. Un sistema puede permitir consultar determinados recursos, pero no modificarlos.
Otro puede exponer solamente parte de la información necesaria. Y determinadas operaciones pueden requerir mecanismos diferentes a una API FHIR. Por eso, antes de diseñar una integración, conviene comprobar qué interfaces ofrece realmente el proveedor del HIS/EHR y cuáles están soportadas para el caso de uso.
FHIR proporciona un lenguaje común para intercambiar información. No sustituye el diseño del proceso que debe utilizarla.
No todos los hospitales empiezan desde la misma arquitectura
Algunos entornos sanitarios disponen de APIs modernas y mecanismos de integración documentados. Otros utilizan interfaces HL7 anteriores, mensajería, servicios especializados o integraciones desarrolladas durante años. También pueden existir soluciones cuya información solo está disponible mediante mecanismos controlados de exportación.
No es necesario imponer una tecnología idéntica a todos los hospitales. La arquitectura debería partir de las capacidades reales del entorno. Cuando existen APIs soportadas, pueden constituir un punto de integración adecuado.
Cuando no existen, es necesario evaluar mecanismos alternativos autorizados por el proveedor. Lo importante es no construir una dependencia frágil sobre interfaces no soportadas. Una integración debe poder mantenerse cuando el sistema clínico cambia de versión, modifica sus interfaces o introduce nuevas restricciones.
Microsoft como capa de integración y operación
En hospitales que ya utilizan Microsoft 365 y Azure, parte de la coordinación entre sistemas puede implementarse mediante componentes del ecosistema Microsoft. Power Platform puede ayudar a crear aplicaciones operativas y automatizar determinados flujos. Azure puede proporcionar servicios de integración, procesamiento y exposición controlada de APIs.
Microsoft Teams puede facilitar tareas y coordinación entre equipos. Power BI puede ofrecer visibilidad sobre indicadores y resultados. Microsoft Entra ID puede proporcionar controles de identidad y acceso para los componentes que correspondan.
Esto no significa que Microsoft deba sustituir el HIS/EHR. Tampoco significa que todos los datos clínicos deban trasladarse a Azure. La decisión depende de la arquitectura, los requisitos de protección de datos, las interfaces disponibles y el caso de uso.
Una capa de integración puede proporcionar valor manteniendo los sistemas clínicos existentes en su función original.
Un ejemplo: recuperar una cita cancelada
Consideremos un proceso de recuperación de capacidad asistencial. El paciente informa de que no podrá acudir. El sistema de agenda registra la cancelación.
Una integración controlada identifica que existe capacidad disponible. Un flujo operativo puede iniciar las acciones de comunicación o reprogramación autorizadas. Cuando se confirma una nueva asignación, el estado debe registrarse correctamente en el sistema responsable de la agenda.
Finalmente, un cuadro de mando permite observar si el proceso está recuperando capacidad. Este recorrido puede involucrar varios sistemas. Sin embargo, desde la perspectiva del hospital debería comportarse como un único proceso.
La interoperabilidad permite mantener esa continuidad. El principio también se aplica a otros escenarios: recopilación de feedback, seguimiento administrativo, documentación asistida o coordinación entre diferentes equipos. En todos ellos conviene definir desde el principio qué sistema inicia cada acción y cuál registra el resultado definitivo.
Nuestro análisis sobre recuperación de capacidad asistencial explica cómo abordar uno de estos flujos mediante un piloto operativo medible.
Identidad, seguridad y minimización de datos
Cada nueva integración introduce una frontera que debe protegerse. Un componente que necesita consultar disponibilidad de agenda no debería recibir automáticamente acceso a información clínica completa. Del mismo modo, una herramienta analítica puede trabajar con indicadores agregados cuando no necesita identificar individualmente a los pacientes.
Las decisiones de seguridad deben responder a la finalidad del proceso. Es necesario definir quién realiza cada acción, con qué identidad, qué permisos necesita y cómo se registra la actividad relevante. También debe existir una política sobre almacenamiento, retención y eliminación de datos.
Cuando participan sistemas de identidad diferentes, no debe asumirse que una identidad de empleado y una identidad de paciente pueden gestionarse mediante el mismo modelo. La arquitectura tiene que distinguir claramente esos contextos. En entornos europeos, estas decisiones deben evaluarse considerando el RGPD y las obligaciones aplicables al tratamiento de datos sanitarios.
La interoperabilidad no elimina las responsabilidades sobre protección de datos. Las hace especialmente importantes.
Una integración necesita gestionar errores y excepciones
Los procesos distribuidos pueden fallar. Una API puede no responder. Una comunicación puede no entregarse.
Un sistema puede registrar una actualización que otro todavía no ha recibido. Una modificación puede llegar duplicada. Por eso la integración no debería diseñarse únicamente para el escenario en que todo funciona correctamente.
Debe existir un procedimiento para detectar fallos, evitar acciones duplicadas, volver a intentar operaciones cuando sea seguro hacerlo y reconciliar estados inconsistentes. En un proceso de citas, por ejemplo, es fundamental evitar que un mismo hueco termine asignado incorrectamente a varias personas. La lógica de confirmación debe permanecer bajo el control del sistema autorizado para gestionar esa disponibilidad.
También resulta importante que los equipos puedan identificar qué ha ocurrido cuando aparece una excepción. La integración operativa no consiste solamente en conectar aplicaciones. Consiste en mantener un resultado consistente incluso cuando algo falla.
Analítica sin crear otra fuente de verdad
La interoperabilidad también permite construir indicadores más útiles. Un hospital puede querer medir capacidad recuperada, tiempo administrativo, experiencia del paciente o eficacia de determinados flujos digitales. Para ello puede necesitar señales procedentes de varios sistemas.
Power BI puede reunir esas señales en un cuadro de mando, utilizando una arquitectura de datos adecuada. Pero el dashboard no debería convertirse en un nuevo lugar donde los equipos deban actualizar manualmente la información. Las métricas deberían derivarse de fuentes definidas y conservar un significado consistente.
Esto permite observar los resultados del proceso sin duplicar su operación.
Nuestro artículo sobre analítica operativa sanitaria profundiza en cómo seleccionar indicadores vinculados a decisiones reales.
Azure Health Data Services y la evolución de FHIR
Microsoft ofrece Azure Health Data Services como plataforma de servicios gestionados basados en estándares sanitarios. Dentro de este conjunto, el servicio FHIR permite almacenar e intercambiar determinados datos sanitarios mediante interfaces compatibles con el estándar. Puede ser útil en arquitecturas que necesitan una capa de intercambio sanitario en Azure.
Sin embargo, no debería incorporarse automáticamente a cualquier proyecto. Si un hospital solamente necesita conectar un evento administrativo con un flujo operativo, puede existir una solución más sencilla. La elección depende de los datos, las necesidades de interoperabilidad y la arquitectura existente.
También es importante utilizar servicios vigentes. Según su documentación actualizada, Microsoft marcó Azure API for FHIR, su oferta anterior, como obsoleto (deprecated) el 30 de septiembre de 2026. Las nuevas arquitecturas que necesiten un servicio FHIR gestionado deben evaluar Azure Health Data Services FHIR service y sus capacidades actuales.
La decisión sigue siendo arquitectónica. No existe una obligación universal de utilizar un servidor FHIR en Azure para mejorar los procesos sanitarios.
El Espacio Europeo de Datos Sanitarios cambia el contexto
La interoperabilidad también está adquiriendo mayor relevancia regulatoria en Europa. El Reglamento del Espacio Europeo de Datos Sanitarios, conocido como EHDS, establece un marco europeo para mejorar el acceso, intercambio y utilización de determinados datos sanitarios electrónicos. El reglamento entró en vigor el 26 de marzo de 2025. Su aplicación es progresiva, con hitos importantes en 2029 y 2031 según las categorías de datos y las obligaciones correspondientes.
Las obligaciones relacionadas con diferentes categorías de datos y determinados sistemas de historia clínica electrónica se incorporan en varias fases. Esto no significa que todos los hospitales deban sustituir inmediatamente sus plataformas. Pero sí refuerza la importancia de comprender las capacidades de interoperabilidad disponibles, las dependencias de proveedores y la evolución de los requisitos técnicos.
Para una organización sanitaria, empezar hoy por integraciones documentadas y gobernadas puede ayudar a reducir complejidad futura. La prioridad debería continuar siendo resolver necesidades reales sin perder control sobre los sistemas y los datos.
Empezar por una integración, no por toda la arquitectura hospitalaria
La interoperabilidad puede parecer un proyecto de transformación de gran escala. No tiene por qué comenzar así. Un piloto puede centrarse en un proceso donde ya existe una necesidad operativa identificada.
Por ejemplo, cancelación y recuperación de citas. El alcance inicial puede limitarse a comprobar las interfaces disponibles, definir los datos necesarios, establecer permisos, integrar el flujo y medir el resultado. Antes de ampliar ese alcance debería verificarse que el proceso funciona, que las excepciones pueden gestionarse y que la integración puede mantenerse.
Esto permite generar evidencia sin comprometer toda la arquitectura desde el primer día.
Es el mismo principio que aplicamos al paso de piloto a producción: una solución debe demostrar no solamente que funciona, sino que puede operarse de manera segura y sostenible.
Cómo lo plantea Cleverina
Cleverina aborda la interoperabilidad sanitaria desde los procesos que necesitan mejorar. Nuestros tres pilares —gestión inteligente de citas, inteligencia de la experiencia del paciente y documentación clínica asistida por IA— pueden involucrar diferentes sistemas dentro del hospital. El objetivo no es construir una plataforma paralela.
Es identificar qué información debe circular, qué acciones están autorizadas, cómo deben protegerse los datos y qué resultados necesitan medirse. Utilizamos las capacidades del ecosistema Microsoft cuando aportan valor, integrándolas con los sistemas HIS/EHR y las herramientas especializadas que la organización ya utiliza. Cada proyecto comienza con un alcance concreto, una arquitectura adecuada al entorno y métricas que permitan evaluar el resultado.
Una buena integración no se reconoce por la cantidad de sistemas conectados, sino por la cantidad de fricción que elimina sin perder control.