Alta y baja de un empleado en el software clínico: el ciclo completo de permisos

1. Por qué los permisos tienen un ciclo de vida

Un permiso que se concede y no se revisa ni se retira es un riesgo acumulado. Las clínicas contratan, forman, cambian funciones y despiden personal de forma continua. Cada uno de esos movimientos debería tener un reflejo en el sistema de permisos, y en la mayoría de las clínicas no lo tiene. El resultado son cuentas activas de personas que ya no trabajan allí, permisos de funciones anteriores que nadie retiró y accesos que se otorgaron para un proyecto temporal que terminó hace meses.

1.1. El permiso olvidado: el riesgo que no se ve

Un permiso que sigue activo después de que su justificación ha desaparecido es invisible hasta que alguien lo usa indebidamente. La recepcionista que dejó la clínica hace seis meses pero cuya cuenta sigue activa no genera ninguna alerta mientras nadie la use. Pero si alguien conoce sus credenciales —ella misma, un compañero que las anotó, o un atacante que las obtuvo— esa cuenta es una puerta abierta a todos los historiales a los que tenía acceso. El coste de cerrar esa puerta el día de la baja es cercano a cero. El coste de no cerrarla puede ser una brecha de seguridad.

1.2. El principio de mínimo privilegio aplicado al empleo

El principio de mínimo privilegio dice que cada usuario debe tener únicamente los permisos que necesita para su función actual, y solo durante el tiempo que los necesite. Aplicado al ciclo de empleo, esto significa que los permisos se conceden el día que la persona empieza, se ajustan cada vez que su función cambia y se retiran el día que se va. No es un ideal teórico: es la medida más básica que el RGPD exige a cualquier responsable del tratamiento de datos personales, y los datos sanitarios lo exigen con más razón.

2. El alta: qué permisos necesita el primer día

El primer día de un empleado en la clínica debería estar planificado antes de que llegue. Eso incluye sus credenciales de acceso al sistema, su rol asignado y los permisos que ese rol lleva asociados.

2.1. Asignar el rol antes de crear la cuenta

El proceso correcto es decidir qué rol corresponde al puesto antes de crear la cuenta del usuario. Si la clínica tiene roles predefinidos, la decisión es directa: un médico recibe el rol de médico, una recepcionista el de recepción, un DPO el de auditor. Si la clínica no tiene roles definidos, el primer empleado nuevo va a recibir un conjunto improvisado de permisos que se convierte en el estándar informal para los siguientes. Ese estándar informal tiende a ser demasiado amplio, porque quien lo configura prefiere errar por exceso para no recibir quejas el primer día.

2.2. Credenciales individuales: una persona, una cuenta

Cada empleado necesita su propia cuenta con su propia contraseña. Las cuentas compartidas —una cuenta de «recepción» que usan las tres recepcionistas— impiden saber quién hizo qué. Si se produce un acceso indebido desde una cuenta compartida, la investigación no puede determinar qué persona física lo cometió. La traza registra «recepción accedió al historial de este paciente», no quién de las tres estaba sentada delante de la pantalla. Para la AEPD, una cuenta compartida es una deficiencia de seguridad del tratamiento.

2.3. La formación del primer día: qué puede y qué no puede hacer

Dar acceso sin formación es dar una herramienta sin instrucciones. El empleado necesita saber, el primer día, a qué tiene acceso, a qué no tiene acceso, por qué esas diferencias existen y qué ocurre si accede a algo que no le corresponde. No es un curso de dos horas: son diez minutos que establecen las expectativas y que, en caso de incidente, demuestran que la clínica cumplió su deber de informar. Un acceso indebido cometido por alguien al que nunca se le explicó qué era indebido es responsabilidad de la clínica, no solo del individuo.

3. El periodo de prueba y los permisos provisionales

Los primeros días o semanas de un empleado son un periodo de observación recíproca. La clínica observa al empleado y el empleado conoce la clínica. Los permisos de este periodo no tienen por qué ser los mismos que los definitivos.

3.1. Permisos reducidos al arrancar

Un empleado en periodo de prueba puede empezar con un subconjunto del rol que le corresponde: acceso a las pantallas que necesita para la formación práctica, sin acceso a funciones que requieren autonomía plena. Un médico nuevo puede necesitar acceder a historiales pero no a funciones de exportación o borrado hasta que haya completado la formación interna. Una recepcionista puede empezar con acceso a la agenda pero sin acceso a la facturación hasta que se haya familiarizado con el sistema de citas.

3.2. La ampliación progresiva

A medida que el empleado demuestra competencia y completa formaciones internas, sus permisos se amplían hasta cubrir el rol completo. Este proceso debería estar documentado: quién autoriza la ampliación, cuándo se produce y por qué. No tiene que ser un procedimiento pesado: basta con que alguien —el responsable directo o el administrador del sistema— registre que se ha ampliado el acceso y el motivo. Esa documentación es la prueba de que los permisos se concedieron de forma controlada, no por inercia.

4. Mientras dura la relación: cuándo revisar los permisos

Un empleado que lleva tres años en la clínica puede estar haciendo lo mismo que el primer día o puede haber cambiado de funciones dos veces. Sus permisos deberían reflejar lo que hace hoy, no lo que hacía cuando llegó.

4.1. La revisión periódica: mínimo una vez al año

La revisión periódica de permisos es la herramienta que detecta las discrepancias entre lo que un empleado puede hacer en el sistema y lo que necesita hacer. Una revisión anual es el mínimo razonable. En clínicas con alta rotación o con cambios frecuentes de funciones, una revisión semestral es más adecuada. La revisión la hace el administrador del sistema o el responsable de seguridad, cruzando la lista de usuarios activos con la lista de personal en nómina y comparando los permisos asignados con los que corresponden al puesto actual.

4.2. Los eventos que disparan una revisión anticipada

Además de la revisión periódica, hay eventos que deben disparar una revisión inmediata de los permisos de un empleado: un cambio de puesto o de funciones, una excedencia, una baja médica prolongada, una incidencia de seguridad en la que esté implicado o un cambio en la normativa que afecte a su perfil de acceso. No se trata de revisar todos los permisos del sistema: se trata de ajustar los de la persona afectada por el evento, antes de que la discrepancia genere un riesgo.

5. Cambio de función dentro de la clínica

Un empleado que cambia de puesto dentro de la clínica necesita nuevos permisos para su nueva función y la retirada de los permisos que ya no le corresponden. Lo habitual es que se añadan los nuevos y nadie retire los antiguos. Eso se llama acumulación de privilegios, y es uno de los problemas más frecuentes en el control de accesos de las organizaciones sanitarias.

5.1. La acumulación de privilegios: el riesgo silencioso

Un médico que pasa a un puesto de coordinación y conserva su acceso de médico tiene más permisos de los que necesita para ninguna de las dos funciones. Un administrativo que pasa a recepción y conserva su acceso a facturación tiene una ventana a datos que ya no gestiona. La acumulación se produce porque añadir permisos es fácil y visible —el empleado pide los nuevos— y retirarlos es invisible —nadie pide que se los quiten—. El resultado, al cabo de unos años, son usuarios con permisos que ningún rol individual justifica.

5.2. El cambio de rol como operación atómica

La forma de evitar la acumulación es tratar el cambio de función como un cambio de rol, no como una suma de permisos. Si el empleado pasa de médico a coordinador, se le retira el rol de médico y se le asigna el de coordinador. Si el coordinador necesita puntualmente acceder a una función de su rol anterior, ese acceso se concede como excepción documentada con fecha de caducidad, no como un permiso permanente que se olvida.

6. La baja voluntaria: el protocolo del último día

Cuando un empleado comunica su baja voluntaria, la clínica tiene un periodo de preaviso —habitualmente quince días— para planificar la transición. Ese periodo debe incluir la planificación de la retirada de accesos.

6.1. Antes del último día: preparar la desactivación

La desactivación de la cuenta no se improvisa el último día. Se prepara durante el preaviso: se identifica qué accesos tiene el empleado, se verifica que no hay tareas pendientes que requieran su acceso después de irse y se establece quién va a asumir las funciones que deja. Si el empleado gestionaba agendas de pacientes, alguien tiene que asumir esas agendas antes de que se le retire el acceso. Si tenía acceso a informes que otros necesitan, se transfiere la responsabilidad antes, no después.

6.2. El día de la baja: desactivación completa

El último día laborable, antes de que el empleado se vaya, su cuenta se desactiva. No se borra: se desactiva. La diferencia importa. Una cuenta borrada pierde la trazabilidad de sus acciones pasadas. Una cuenta desactivada conserva el historial de lo que hizo pero impide cualquier acceso futuro. La desactivación incluye el cierre de sesiones activas, el cambio de contraseña como medida preventiva y la verificación de que no existen accesos desde dispositivos personales que pudieran seguir activos.

7. La baja inmediata: despido o abandono

Cuando la baja no es voluntaria o el empleado deja de acudir sin previo aviso, no hay periodo de preaviso. La desactivación debe ser inmediata.

7.1. El despido: desactivar antes de comunicar

En un despido, la recomendación es desactivar la cuenta del empleado antes de la comunicación de la decisión o simultáneamente. Si el empleado conoce la decisión antes de que se le retire el acceso, existe el riesgo de que acceda al sistema para copiar, modificar o borrar información. No es un escenario habitual, pero la prevención no cuesta nada y la recuperación puede ser imposible. El administrador del sistema desactiva la cuenta; recursos humanos comunica la decisión. Las dos acciones deben estar coordinadas.

7.2. El abandono: detectar y reaccionar

Cuando un empleado deja de acudir sin previo aviso, la clínica tarda en confirmar que se trata de un abandono y no de una ausencia temporal. Durante ese periodo, la cuenta sigue activa. La buena práctica es desactivar la cuenta al tercer día de ausencia injustificada sin contacto, como medida preventiva. Si el empleado reaparece con una justificación legítima, reactivar la cuenta es sencillo. Si no reaparece, la cuenta ya está cerrada.

7.3. La urgencia del cierre en situaciones de conflicto

Si la baja se produce en un contexto de conflicto —despido disciplinario, denuncia por parte del empleado, disputa laboral— la urgencia de la desactivación es máxima. Un empleado en conflicto con la clínica que conserva acceso al sistema es un riesgo activo, no hipotético. La desactivación debe hacerse de forma inmediata y documentada, y la traza de accesos de los días anteriores al conflicto debe revisarse para descartar que el empleado haya tomado medidas anticipándose a la situación.

8. La lista de verificación que evita los olvidos

El protocolo de alta y baja de permisos funciona cuando es una lista de pasos que se ejecutan siempre, no cuando depende de que alguien se acuerde. La lista de verificación convierte el protocolo en un procedimiento replicable.

8.1. Lista de alta: los diez puntos

La lista de alta incluye: confirmar el puesto y el rol correspondiente, crear la cuenta con credenciales individuales, asignar el rol, verificar que los permisos del rol cubren lo necesario y nada más, entregar las credenciales de forma segura, registrar la fecha de alta en el sistema, programar la ampliación de permisos si se aplica un periodo provisional, documentar la formación inicial sobre acceso y protección de datos, firmar el compromiso de confidencialidad y programar la primera revisión de permisos.

8.2. Lista de baja: los ocho puntos

La lista de baja incluye: confirmar la fecha efectiva de baja, desactivar la cuenta en el sistema, cerrar sesiones activas, revocar accesos desde dispositivos externos si los hubiera, transferir las responsabilidades pendientes, archivar la documentación del empleado relacionada con accesos y formación, actualizar la lista de usuarios activos y verificar en la traza que no se produjo ningún acceso irregular en los días previos a la baja.

8.3. Quién ejecuta la lista y quién la verifica

La lista la ejecuta el administrador del sistema o la persona designada para gestionar accesos. La verificación la hace una segunda persona: el responsable de seguridad, el DPO o el superior directo del empleado. La verificación no duplica el trabajo: confirma que se han completado todos los pasos. Un paso olvidado en la lista de baja —una sesión que no se cerró, un dispositivo que no se revocó— es un agujero que puede tardar meses en detectarse.

9. Qué aporta obeliOmed

obeliOmed estructura el ciclo de permisos alrededor de los roles. Cuando se da de alta un empleado, se le asigna un rol predefinido que ya tiene los permisos correctos para su función. Cuando se da de baja, la desactivación de la cuenta cierra todos los accesos asociados al rol en una sola acción.

9.1. Alta con rol predefinido y permisos listos

Los roles predefinidos de obeliOmed están diseñados para cubrir las funciones habituales de una clínica desde el primer día. El administrador crea la cuenta, asigna el rol y el empleado tiene acceso exactamente a lo que necesita. No hay que configurar permisos uno a uno, no hay que copiar los permisos de otro empleado «que hace lo mismo» y no hay que improvisar un conjunto de accesos que luego nadie revisa.

9.2. Desactivación que cierra todo de una vez

Desactivar una cuenta en obeliOmed desactiva el acceso a todas las pantallas, cierra las sesiones activas y marca la cuenta como inactiva en la traza. La cuenta no se borra: sigue siendo visible en el historial de accesos con todo su recorrido. Si el informe de accesos del DPO necesita revisar qué hizo ese empleado durante su periodo en la clínica, la información está ahí. Lo que ya no puede hacer es acceder de nuevo.