Qué pasa cuando un usuario no tiene rol en la clínica: el hueco que nadie revisa

1. Cómo llega un usuario a no tener rol en el sistema

No es un caso raro ni un error de laboratorio. Es algo que ocurre en clínicas reales, con frecuencia, por razones que parecen inocentes en el momento y que solo se descubren cuando alguien pregunta o cuando algo sale mal.

1.1. El alta urgente: primero el acceso, después la configuración

Un empleado se incorpora un lunes a primera hora. El administrador crea el usuario para que pueda entrar, pero pospone la asignación del rol porque «tiene que mirar qué pantallas necesita». El empleado ya tiene acceso al sistema. Si el software trata la ausencia de rol como acceso total, la persona ve todo. Si la trata como acceso nulo, la persona no puede trabajar. En ambos casos, la situación es provisional y en ambos casos tiende a no resolverse hasta que alguien se queja.

1.2. La baja incompleta: se desactiva la persona pero no el usuario

Un empleado deja la clínica. Recursos humanos lo da de baja en nómina. Nadie avisa al administrador del sistema. El usuario sigue activo, con o sin rol, y es un punto de entrada que no debería existir. Lo que implica la baja de un empleado en los permisos va más allá de la nómina.

1.3. El cambio de función que retira todos los roles sin asignar el nuevo

Un enfermero pasa a coordinación. El administrador le quita el rol de enfermero, pero no le asigna el de coordinador porque aún no sabe cuál es. Durante los días que tarda en resolverlo, la persona está en el sistema sin rol. Si intenta entrar, lo que vea depende de cómo el software gestione ese vacío.

2. Qué debería pasar cuando un usuario no tiene rol: acceso cero

La respuesta correcta es que un usuario sin rol no vea nada. Ni la agenda, ni la historia clínica, ni la facturación, ni la configuración. Si no tiene rol, no tiene función definida en el sistema, y si no tiene función, no hay justificación para que acceda a ningún dato.

2.1. El principio de mínimo privilegio aplicado al caso extremo

El principio de mínimo privilegio dice que cada persona accede solo a lo que necesita. Alguien sin rol asignado no necesita nada, porque el sistema no sabe qué función cumple. El acceso correcto es cero: la persona puede iniciar sesión —tiene usuario y contraseña—, pero no ve ninguna pantalla. Lo que ve es un mensaje que le indica que hable con el administrador. Eso obliga a resolver la situación en lugar de convivir con ella.

2.2. Por qué el acceso total por defecto es el peor diseño posible

Algunos sistemas tratan la ausencia de rol como acceso sin restricciones: si no hay regla que lo prohíba, se permite todo. Eso invierte la lógica de seguridad. En un entorno con datos de salud, la lógica correcta es la contraria: si no hay regla que lo permita, se deniega. Un usuario sin rol con acceso total puede consultar cualquier historia clínica, exportar datos y modificar registros sin que ningún rol lo ampare. Si eso ocurre y alguien lo detecta, la clínica no tiene defensa.

3. Qué pasa de verdad en muchos sistemas cuando falta el rol

La teoría es clara. La práctica depende del software que use la clínica, y no todos lo resuelven igual.

3.1. Acceso total silencioso

El caso más peligroso: el usuario entra y ve todo. El sistema no alerta al administrador, no genera un aviso y no registra que el acceso ocurrió sin rol definido. La persona trabaja con normalidad, y nadie se da cuenta de que sus accesos no están amparados por ninguna política. La primera vez que alguien lo descubre suele ser durante una auditoría externa, cuando ya han pasado meses y los registros de acceso muestran consultas que no se pueden justificar.

3.2. Acceso parcial heredado

Algunos sistemas conservan los permisos del último rol asignado aunque se haya retirado. El enfermero que pasó a coordinación y al que le quitaron el rol de enfermero sigue viendo las pantallas de enfermería. No porque tenga rol, sino porque el sistema no limpió los permisos al retirar el rol. Es un acceso residual que no está amparado por ninguna política vigente.

3.3. Bloqueo sin explicación

El mejor caso de los malos: el usuario entra y no ve nada, pero el sistema no le dice por qué. La persona piensa que hay un error técnico, llama al administrador, y la solución rápida es «darle acceso a algo para que pueda trabajar». El resultado es una asignación improvisada que nadie documenta. El bloqueo funcionó, pero el proceso para resolverlo convirtió la solución en otro problema.

4. El riesgo legal de un acceso sin rol definido

El RGPD y la LOPDGDD exigen que el acceso a datos de salud esté justificado, documentado y limitado a lo necesario. Un acceso sin rol no cumple ninguna de las tres condiciones.

4.1. No hay justificación documentada

Si alguien accede a una historia clínica sin tener un rol que incluya esa pantalla, la clínica no puede explicar por qué tuvo acceso. La auditoría de accesos a la historia clínica detectará consultas que no encajan con ningún rol, y la respuesta «no tenía rol asignado» es peor que cualquier otra explicación, porque demuestra que el control de acceso falló en su capa más básica.

4.2. No hay límite al daño

Un usuario con rol puede acceder a las pantallas de ese rol. Un usuario sin rol con acceso total puede acceder a todo. Si esa persona consulta, modifica o exporta datos que no debería haber visto, el alcance del incidente es máximo porque no había ningún perímetro que lo contuviera.

4.3. La responsabilidad proactiva exige que no ocurra

El principio de responsabilidad proactiva del RGPD obliga a la clínica a tomar medidas para prevenir, no solo para reaccionar. Que un usuario pueda estar en el sistema sin rol es una medida que no se tomó. Cuando la inspección pregunta «¿qué pasa si un usuario no tiene rol asignado?», la respuesta debería ser «no puede ver nada». Si la respuesta es «no lo hemos probado», la inspección tiene un hallazgo.

5. Cómo detectar usuarios sin rol en el sistema

El primer paso para resolver el problema es saber si existe. Y no siempre es evidente.

5.1. La lista de usuarios activos sin rol asignado

El administrador debería poder sacar un listado de usuarios activos que no tienen ningún rol. Si el sistema no ofrece ese filtro, la alternativa es exportar la lista de usuarios y la lista de asignaciones de roles, y cruzarlas. Los usuarios que aparecen en la primera pero no en la segunda son los que hay que revisar. En una clínica con rotación, esta lista debería consultarse al menos una vez al mes.

5.2. Las cuentas inactivas que siguen activas

No todos los usuarios sin rol son empleados en activo. Algunos son cuentas de empleados que ya no están, que nunca se desactivaron. Esas cuentas son un riesgo adicional porque nadie las vigila y, si el sistema permite el acceso sin rol, son puntos de entrada sin propietario.

5.3. Los usuarios de prueba y los técnicos temporales

Otro caso habitual: cuentas creadas para pruebas, para demostraciones o para que un técnico externo haga un mantenimiento. Esas cuentas suelen crearse sin rol definido, porque se asume que son temporales. Si no se desactivan cuando termina su uso, quedan como usuarios sin rol en el sistema, con un acceso que depende de cómo el software gestione ese vacío.

6. Cómo evitar que un usuario acabe sin rol

La prevención es más simple que la detección. Se trata de que el proceso no permita el hueco.

La primera comprobación cuando un profesional dice que no ve nada es mirar si tiene rol asignado: el problema más frecuente es el más simple.

6.1. El rol como campo obligatorio en el alta

Si el sistema no permite crear un usuario sin asignarle al menos un rol, el problema desaparece en origen. No se puede posponer lo que es obligatorio. El administrador tiene que elegir un rol antes de guardar el usuario nuevo, y si no sabe cuál es, tiene que averiguarlo antes de crear la cuenta. Es un minuto de trabajo que ahorra horas de investigación después.

6.2. La alerta automática cuando se retira el último rol

Si un administrador retira un rol y el usuario se queda sin ninguno, el sistema debería avisar: «Este usuario se quedará sin acceso. ¿Es intencionado?» Si la respuesta es sí, la cuenta debería desactivarse. Si la respuesta es no, hay que asignar otro rol antes de quitar el actual. Ese aviso es la diferencia entre un vacío intencionado y un olvido.

6.3. La revisión periódica como red de seguridad

Incluso con las dos medidas anteriores, la revisión periódica de permisos debería incluir la búsqueda de usuarios activos sin rol. Si aparece alguno, es señal de que algún proceso falló, y el hallazgo debería resolverse el mismo día.

7. Qué hacer cuando se descubre un usuario sin rol

El descubrimiento no es el final: es el principio de una investigación breve pero necesaria.

7.1. Determinar si el usuario accedió a datos

Lo primero es revisar el registro de accesos de ese usuario. Si no consultó ninguna pantalla con datos de paciente, el riesgo se queda en potencial. Si consultó alguna, hay que evaluar si lo que vio estaba justificado por otra vía —una urgencia, una instrucción verbal— y documentar la conclusión. Si no hay justificación, el acceso fue indebido y puede requerir las medidas previstas en qué hacer ante un acceso indebido a la historia clínica.

7.2. Asignar un rol o desactivar la cuenta

Si la persona sigue en la clínica y tiene una función, se le asigna el rol que corresponda. Si ya no está o la cuenta era temporal, se desactiva. No hay tercera opción: un usuario activo sin rol no debería existir ni un día más.

7.3. Documentar el incidente

Aunque no haya habido acceso a datos, el hallazgo se documenta: cuándo se detectó, cuánto tiempo estuvo el usuario sin rol, qué accesos tuvo en ese periodo y qué se hizo para resolverlo. Esa documentación es lo que permite demostrar que la clínica detectó el problema y lo corrigió, que es exactamente lo que la responsabilidad proactiva exige.

8. El rol como paso obligatorio del proceso de alta

La mayoría de los problemas de usuarios sin rol se resuelven integrando la asignación del rol en el proceso de incorporación. Si el rol es parte del alta, como la firma del contrato o la entrega de la tarjeta de acceso, el hueco no se produce.

8.1. La checklist de incorporación que incluye el rol

Cada nueva incorporación debería pasar por una lista de verificación que incluya: contrato firmado, credenciales de acceso creadas, rol asignado, centro vinculado. Si falta cualquiera de los cuatro, la incorporación no está completa. Cuando el proceso lo deja claro, nadie asume que «ya se hará después».

8.2. La responsabilidad compartida entre RRHH y el administrador del sistema

El departamento de recursos humanos sabe cuándo se incorpora alguien y qué función tendrá. El administrador del sistema sabe qué rol corresponde a esa función. Si los dos no se hablan, el resultado es un usuario sin rol. La comunicación entre ambos no tiene que ser compleja: basta con que RRHH avise al administrador con suficiente antelación y con la información necesaria para elegir el rol correcto.

9. Qué aporta obeliOmed cuando un usuario no tiene rol

obeliOmed trata la ausencia de rol como acceso cero, no como acceso total. El diseño del sistema parte del principio de que si no hay regla que permita, se deniega.

9.1. Sin rol, sin menú

Un usuario sin rol asignado inicia sesión y ve una pantalla vacía con un aviso que le indica que hable con el administrador. No ve ninguna pantalla, no puede consultar ningún dato y no puede ejecutar ninguna acción. El aviso es intencionado: obliga a resolver la situación en lugar de ignorarla.

9.2. Alerta al administrador

Cuando un usuario sin rol intenta acceder, el sistema genera un aviso para el administrador. Ese aviso queda registrado y permite identificar cuentas que se crearon sin completar el proceso de alta. No es un error: es una señal de que algo falta, y el sistema la hace visible para que se resuelva.

9.3. Listado de usuarios sin rol en la herramienta de administración

El administrador tiene acceso a un filtro que muestra los usuarios activos sin rol asignado. Esa lista debería estar vacía. Si no lo está, cada entrada es una tarea pendiente que se resuelve asignando un rol o desactivando la cuenta. No hay usuarios sin rol que «están bien así»: cada uno es un hueco en la política de accesos.