Cómo diseñar un intercambio seguro de datos sanitarios sin sustituir los sistemas clínicos existentes ni perder visibilidad sobre quién accede a la información.
La transformación digital de un hospital suele comenzar con una necesidad concreta: mejorar la gestión de citas, conectar aplicaciones, facilitar la comunicación con pacientes o automatizar determinados procesos administrativos.
Sin embargo, cuando una nueva solución necesita intercambiar información con el HIS/EHR, aparece una pregunta fundamental: ¿quién está autorizado a acceder a qué información, en qué condiciones y cómo puede comprobarse posteriormente lo ocurrido?
Una integración puede funcionar técnicamente y seguir presentando riesgos importantes si no se han definido correctamente las identidades, los permisos y la trazabilidad.
La interoperabilidad no consiste únicamente en conectar sistemas. También requiere establecer responsabilidades y límites claros entre ellos.
1. No todas las identidades son iguales
En un hospital conectado conviven diferentes tipos de identidad.
Profesionales sanitarios
Médicos, enfermería y otros profesionales necesitan acceder a información relacionada con sus funciones. El alcance de ese acceso debe responder a responsabilidades y circunstancias asistenciales reales.
Personal administrativo
Los equipos de admisión o gestión de citas pueden necesitar consultar información operativa, pero no necesariamente el contenido clínico completo del paciente.
Pacientes
Los portales y aplicaciones dirigidos a pacientes requieren mecanismos de identificación, autorización y protección adaptados a sus usuarios y funciones.
Aplicaciones e integraciones
Un proceso automatizado que conecta el HIS/EHR con otro sistema también necesita identificarse y operar con permisos definidos.
El error aparece cuando estas identidades se tratan como si fueran equivalentes.
Una cuenta de servicio utilizada para recuperar disponibilidad de citas no debería recibir automáticamente acceso a toda la historia clínica. Del mismo modo, un usuario autenticado correctamente no debería poder consultar cualquier información simplemente porque haya iniciado sesión.
2. Autenticación y autorización son decisiones diferentes
La autenticación permite comprobar una identidad. La autorización determina qué puede hacer esa identidad.
En una arquitectura sanitaria, ambas decisiones deben coordinarse, pero no confundirse.
Por ejemplo, una aplicación de gestión de citas podría necesitar:
- Consultar disponibilidad de determinados servicios.
- Solicitar cambios de una cita mediante una interfaz autorizada.
- Recibir confirmación del sistema responsable.
- Registrar el resultado operativo.
No debería necesitar acceso indiscriminado a diagnósticos, tratamientos o documentación clínica.
Este principio de acceso mínimo debe aplicarse también a los procesos automatizados, cuentas técnicas, integraciones y proveedores externos.
El resultado esperado es una arquitectura en la que cada componente dispone únicamente de las capacidades necesarias para ejecutar su función.
3. La trazabilidad debe recorrer todo el proceso
Tener registros técnicos no significa necesariamente disponer de una trazabilidad completa.
Pensemos en una cancelación de cita.
Un paciente comunica que no podrá acudir. La aplicación recibe la solicitud, un servicio de integración la procesa, el HIS/EHR confirma el cambio y una herramienta de comunicación puede ofrecer ese horario a otra persona.
Para investigar posteriormente un error, el hospital debería poder reconstruir el recorrido:
- Qué componente recibió la solicitud.
- Qué identidad inició la operación.
- Qué autorización se comprobó.
- Qué sistema modificó el estado de la cita.
- Qué respuesta devolvió.
- Si se produjeron errores, reintentos o accesos inesperados.
Una forma de conseguirlo es utilizar identificadores de correlación que permitan relacionar eventos entre componentes sin incorporar innecesariamente datos clínicos sensibles a los registros.
También deben protegerse los propios logs, establecer periodos de conservación apropiados y controlar quién puede consultarlos.
La trazabilidad útil no consiste en registrar todos los datos disponibles, sino en conservar la evidencia necesaria para comprender y verificar las acciones relevantes.
4. Cada sistema conserva sus responsabilidades
Una arquitectura de integración no debería crear una historia clínica paralela sin una necesidad claramente justificada.
El HIS/EHR y los demás sistemas clínicos autorizados deben conservar sus responsabilidades sobre la información y las operaciones que gestionan.
Las nuevas aplicaciones pueden aportar valor coordinando procesos, mostrando información permitida o automatizando tareas dentro de límites definidos.
Por ejemplo, una herramienta operativa puede consultar disponibilidad del sistema hospitalario y proponer una acción, mientras el sistema autorizado mantiene el control sobre el registro final.
Esta separación reduce duplicidades y facilita determinar dónde deben verificarse los cambios.
Es el mismo enfoque descrito en nuestra guía sobre interoperabilidad sanitaria entre HIS/EHR, Microsoft y procesos operativos.
5. Qué puede aportar el ecosistema Microsoft
En hospitales que utilizan Microsoft 365 y Azure, algunas capacidades de identidad, seguridad e integración pueden apoyarse en servicios ya disponibles.
Microsoft Entra ID puede gestionar identidades corporativas, aplicaciones y determinados mecanismos de autenticación y control de acceso.
Azure puede alojar componentes de integración, APIs y servicios de procesamiento, con identidades de aplicación y configuraciones de acceso apropiadas.
Microsoft Defender puede aportar señales de seguridad sobre los sistemas y cargas compatibles.
Microsoft Purview puede apoyar determinadas necesidades de auditoría y gobernanza de datos dentro de los servicios y escenarios que cubre.
Sin embargo, hay una distinción fundamental: disponer de registros de Microsoft Entra o Microsoft 365 no implica disponer automáticamente de una auditoría completa de las operaciones clínicas realizadas dentro del HIS/EHR.
La trazabilidad de extremo a extremo requiere identificar qué evidencia proporciona cada plataforma y cómo se relacionan sus eventos.
Además, los registros de Microsoft Entra tienen periodos de retención predeterminados que dependen de la licencia y el tipo de registro. Cuando se necesita una conservación más prolongada, debe configurarse una estrategia de conservación apropiada, mediante exportación u otras opciones compatibles con la licencia y el escenario.
6. Por qué esta arquitectura importa para EHDS
El Espacio Europeo de Datos Sanitarios introduce un marco de intercambio y utilización de información sanitaria electrónica que se desplegará progresivamente.
Entre los desarrollos recientes se encuentra el Reglamento de Ejecución (UE) 2026/2099, adoptado en septiembre de 2026, sobre identificación y autenticación interoperables para determinados intercambios transfronterizos de datos sanitarios.
Este contexto refuerza la importancia de distinguir entre identidades corporativas, profesionales, pacientes y mecanismos de confianza entre organizaciones.
Una implementación interna de Microsoft Entra no constituye por sí sola una solución completa de identificación transfronteriza conforme a EHDS.
Las principales fases del marco EHDS contemplan hitos en 2027, 2029 y 2031, con obligaciones distintas según el contexto, los actores y las disposiciones aplicables.
Para comprender estas fases recomendamos nuestra guía: EHDS para hospitales: qué preparar antes de 2029 sin reconstruir el HIS/EHR.
La preparación técnica debería centrarse en conocer las dependencias existentes, identificar las identidades y permisos relevantes y comprender qué información puede intercambiar cada sistema bajo condiciones autorizadas.
7. Siete preguntas para evaluar una integración sanitaria
Antes de conectar una nueva aplicación al entorno hospitalario, conviene responder:
- ¿Qué sistema es responsable de la información que se consulta o modifica?
- ¿Qué identidades humanas o técnicas participan?
- ¿Qué permisos necesita realmente cada componente?
- ¿Cómo se comprueba la autorización antes de ejecutar una acción?
- ¿Qué eventos registra cada sistema y cómo se relacionan?
- ¿Quién puede revisar esos registros y durante cuánto tiempo deben conservarse?
- ¿Qué ocurre si una integración falla, utiliza una identidad comprometida o ejecuta una operación no autorizada?
Estas preguntas ayudan a localizar problemas arquitectónicos antes de ampliar un piloto.
8. Empezar por un proceso concreto
No es necesario transformar toda la arquitectura hospitalaria para mejorar el control.
Un punto de partida razonable consiste en seleccionar un proceso delimitado, como la gestión de cancelaciones o la coordinación administrativa de citas.
El hospital puede documentar las identidades implicadas, revisar permisos, definir los eventos que necesita registrar y comprobar que una operación puede seguirse a través de los sistemas participantes.
El piloto también debería verificar el comportamiento ante errores, las revocaciones de acceso y los mecanismos de supervisión humana cuando correspondan.
Esta evaluación permite identificar mejoras técnicas y organizativas antes de incorporar más procesos o proveedores.
Conclusión: conectar sistemas sin perder el control
La transformación digital sanitaria necesita interoperabilidad, pero también identidades comprensibles, autorizaciones justificadas y evidencia verificable.
El objetivo no es crear otro sistema que concentre información clínica, sino permitir que aplicaciones y procesos trabajen con los sistemas existentes de forma controlada.
Una arquitectura bien diseñada debería permitir responder quién accedió, qué operación realizó, bajo qué autorización y qué sistema mantiene la responsabilidad sobre la información.
Cleverina ayuda a organizaciones sanitarias a evaluar integraciones, identidades, seguridad y gobernanza dentro de proyectos de transformación digital basados en necesidades operativas reales.