Revocar el acceso cuando alguien cambia de puesto en la clínica: el paso que casi nunca se da

1. El problema: los permisos se acumulan

Cada vez que una persona cambia de función y se le dan permisos nuevos sin retirar los anteriores, su cuenta gana una capa de acceso que ya no necesita. Después de dos o tres cambios, la cuenta tiene permisos de todas las funciones que ha desempeñado.

1.1. La acumulación invisible

Nadie se queja de tener más permisos de los necesarios. El profesional que tiene acceso a pantallas que ya no usa simplemente no las abre. El problema no es visible hasta que la revisión periódica lo detecta —si se hace— o hasta que alguien usa los permisos acumulados para algo que no debería, en cuyo caso ya es tarde. La acumulación es silenciosa, progresiva e inevitable si no hay un proceso de revocación.

1.2. Por qué se le da prioridad a asignar pero no a revocar

Cuando alguien cambia de puesto, la urgencia es que pueda trabajar en el nuevo. El administrador del sistema recibe una petición de «dale acceso a coordinación» y la ejecuta. Nadie envía una petición de «quítale acceso a enfermería». La asignación tiene un solicitante con prisa; la revocación no tiene solicitante. Por eso no se hace salvo que haya un proceso que la incluya.

1.3. La diferencia con la baja: aquí la persona sigue activa

Cuando alguien deja la clínica, la gestión de la baja desactiva la cuenta entera. Es una operación limpia: todo o nada. El cambio de puesto es más sutil: la persona sigue trabajando, sigue necesitando acceso al sistema, pero necesita un acceso diferente. La revocación parcial es más difícil de gestionar que la desactivación total, y por eso se olvida con más frecuencia.

2. Cuándo hay que revocar permisos

No todo cambio organizativo requiere una revocación. Pero los que sí la requieren son más de los que parece.

2.1. Cambio de función dentro del mismo centro

Una enfermera que pasa a coordinación, un médico que asume la dirección médica, un auxiliar que pasa a recepción. El rol en el sistema cambia, y los permisos del rol anterior se revocan al asignar el nuevo. Si el profesional va a desempeñar las dos funciones simultáneamente —coordinación y consulta médica—, se le asignan los dos roles con justificación documentada; pero la excepción no anula la regla.

2.2. Cambio de centro

Un profesional que deja de trabajar en el centro A y pasa al centro B necesita que se le desvincule de A y se le vincule a B. Si no se desvincula de A, sigue viendo los pacientes de un centro donde ya no trabaja. La desvinculación de centro es equivalente a la revocación de rol: es un acceso que ya no tiene justificación y que debe retirarse.

2.3. Reducción de responsabilidades

Un profesional que deja de ser jefe de servicio y vuelve a su función base pierde las responsabilidades de supervisión y los permisos que las acompañaban. El acceso a informes de equipo, estadísticas de centro o funciones de administración del servicio ya no le corresponde. La reducción de responsabilidades es un cambio de puesto que suele pasar desapercibido porque la persona «sigue haciendo lo mismo», pero con menos alcance.

3. Qué se revoca y qué se mantiene

La revocación no es binaria. Se retira lo que ya no corresponde y se mantiene lo que sigue siendo necesario.

3.1. Permisos del rol anterior: se revocan

Las pantallas, funciones y datos que eran propios de la función anterior se retiran. Si la persona era enfermera y ahora es coordinadora, el acceso a las notas clínicas de enfermería se retira y se sustituye por el acceso a las herramientas de coordinación. El catálogo de roles define lo que cada función necesita; al cambiar de función, se cambia de rol.

3.2. Permisos comunes a ambas funciones: se mantienen

Si las dos funciones comparten pantallas —por ejemplo, la ficha del paciente o la agenda—, esos permisos se mantienen. La revocación no toca lo que el rol nuevo ya incluye. El resultado debería ser que la cuenta tenga exactamente los permisos del rol nuevo, sin más y sin menos.

3.3. Permisos personalizados: se evalúan

Si la persona tenía permisos adicionales que se le dieron fuera del rol estándar —acceso a un informe especial, permiso de exportación por un proyecto concreto—, esos permisos se evalúan. Si estaban vinculados a la función anterior, se revocan. Si están vinculados a una responsabilidad que sigue vigente, se mantienen con justificación.

4. El proceso de revocación paso a paso

La revocación funciona cuando forma parte del proceso de cambio de puesto, no cuando depende de que alguien se acuerde.

4.1. La notificación del cambio de puesto incluye los permisos

Cuando recursos humanos comunica un cambio de puesto, la comunicación debería incluir la función anterior, la función nueva y la fecha efectiva. Con esa información, el administrador del sistema sabe qué rol retirar, qué rol asignar y cuándo hacerlo. Si la comunicación solo dice «dale acceso a coordinación», el administrador añade sin retirar.

4.2. La revocación se ejecuta el mismo día que la asignación

No hay razón para revocar después de asignar. El día en que la persona empieza en su nueva función es el día en que sus permisos reflejan esa función. Si se necesita un período de transición —por ejemplo, para cerrar asuntos pendientes del puesto anterior—, se define una fecha concreta de revocación y se cumple.

La revocación no es un castigo: es higiene. Un profesional que ya no necesita un acceso no debería tenerlo, por su propia protección.

4.3. La verificación después de la revocación

Después de revocar, se verifica que la persona puede hacer su trabajo con los permisos nuevos y que no accede a nada del puesto anterior. Si algo falta, se añade. Si algo sobra, se investiga por qué la revocación no fue completa. Tres minutos de verificación evitan tres meses de permisos acumulados.

5. Cambio de centro: la otra revocación olvidada

El cambio de centro es la revocación que más se olvida porque la persona sigue haciendo lo mismo, solo que en otro sitio.

5.1. Desvincular del centro anterior, vincular al nuevo

Si un médico que trabajaba en dos centros deja uno de ellos, la desvinculación del centro anterior es la revocación del acceso a los datos de ese centro. Sin ella, el médico sigue viendo pacientes de un centro donde ya no trabaja. El rol no cambia —sigue siendo médico—, pero el perímetro de datos sí.

5.2. La agenda del centro anterior

Si la desvinculación no se hace, la agenda del centro anterior sigue visible para el profesional. No solo ve los datos de los pacientes: ve la agenda completa del centro, con los huecos, las citas de otros profesionales y la disponibilidad. Es un acceso que no tiene justificación asistencial ni operativa una vez que el profesional ya no trabaja allí.

6. La transición: acceso solapado durante el cambio

No todos los cambios de puesto son instantáneos. Algunos requieren un período de transición en el que la persona desempeña las dos funciones.

6.1. Cuándo es legítimo el solapamiento

Un médico que asume la dirección del servicio mientras sigue pasando consulta durante un mes de transición necesita los permisos de las dos funciones temporalmente. Lo importante es que el solapamiento tenga fecha de fin. Si se deja indefinido, se convierte en una acumulación permanente disfrazada de transición.

6.2. Cómo gestionar la fecha de fin

El administrador del sistema registra la fecha en la que los permisos del rol anterior se revocarán. Llegada la fecha, los revoca. No hace falta que nadie se lo recuerde: si el sistema permite programar revocaciones, se programa. Si no lo permite, se anota en el calendario y se cumple. La clave es que la fecha se defina cuando se concede el solapamiento, no cuando alguien se acuerde.

7. Los errores habituales en la revocación

Los errores en la revocación son casi siempre los mismos, y la mayoría se previenen con un proceso claro.

7.1. No revocar porque «no molesta»

El profesional no se queja, el administrador no recibe una petición y los permisos se quedan. La ausencia de queja no es confirmación de que los permisos son correctos: es la consecuencia de que nadie pierde nada cuando tiene más de lo que necesita. La revocación no depende de que alguien se queje, sino de que alguien lo haga.

7.2. Revocar tarde

Tres meses después del cambio de puesto, alguien se da cuenta de que la persona todavía tiene los permisos anteriores. Se revocan, pero durante tres meses la cuenta tuvo un acceso sin justificación. Si en esos tres meses se produjo una consulta inapropiada, la clínica no puede demostrar que los permisos estaban bien gestionados.

7.3. Revocar de más

El administrador, al revocar, retira un permiso que la persona necesita en su nueva función. La persona no puede hacer su trabajo y solicita que se le devuelva el acceso. El resultado es una pérdida de tiempo y una percepción de que «los permisos solo dan problemas». La revocación bien hecha requiere conocer los permisos del rol nuevo antes de tocar los del anterior: se retira lo que sobra, no lo que está.

8. Qué exige la normativa

La normativa no dice «revoque los permisos cuando alguien cambie de puesto». Dice algo más amplio: los datos solo los accede quien los necesita para su función.

8.1. El principio de mínimo privilegio como obligación

El RGPD exige que el acceso a datos personales se limite a lo necesario para cada función. Si una persona ya no desempeña una función, los permisos de esa función ya no son necesarios. Mantenerlos es un incumplimiento del principio de minimización, aunque la persona nunca los use. Lo que la normativa evalúa es la configuración del acceso, no el uso que se le da.

8.2. La responsabilidad del responsable del tratamiento

La clínica —como responsable del tratamiento— responde por los accesos que permite. Si un profesional con permisos acumulados consulta datos que ya no le corresponden, la clínica no puede alegar que «no sabía» que los permisos seguían activos. La responsabilidad proactiva del RGPD exige que la clínica tenga un proceso para mantener los permisos al día, no solo para configurarlos al principio.

9. Qué aporta obeliOmed

obeliOmed gestiona el cambio de puesto como una operación atómica: al asignar un rol nuevo, el sistema muestra los permisos del rol anterior y permite revocarlos en la misma operación.

9.1. Cambio de rol en un solo paso

El administrador selecciona al usuario, le asigna el rol nuevo y el sistema le muestra qué permisos del rol anterior se van a retirar. El cambio se ejecuta completo: asignación y revocación en la misma operación. No hay un segundo paso que olvidar, no hay una petición pendiente que no se envía. Los doce roles base tienen permisos definidos; al cambiar de uno a otro, el resultado es predecible.

9.2. Registro del cambio con fecha y motivo

Cada cambio de rol genera un registro que dice quién lo hizo, cuándo, cuál era el rol anterior y cuál es el nuevo. Ese registro es la evidencia de que el cambio se gestionó correctamente. Si la revisión periódica encuentra que un usuario tiene permisos de un rol que ya no le corresponde, el registro muestra si el cambio se hizo mal o si no se hizo en absoluto.