El rol no es el puesto: por qué confundirlos desordena los permisos de la clínica

1. Qué es un puesto y qué es un rol: las definiciones que importan

El puesto es un concepto laboral. El rol es un concepto de seguridad informática. Los dos existen al mismo tiempo, se refieren a la misma persona, y casi nunca coinciden en lo que implican. Si la clínica no los distingue desde el primer día, todo lo que viene después —los permisos, la auditoría, la respuesta ante un incidente— se monta sobre una base equivocada.

1.1. El puesto: lo que dice el contrato y el organigrama

Un puesto de trabajo es la posición que una persona ocupa en la estructura de la clínica. Médico oftalmólogo, enfermera de planta, recepcionista, directora médica. Lo define el contrato laboral, lo sitúa el organigrama y lo reconoce el convenio colectivo. El puesto determina la categoría profesional, el salario, las responsabilidades asistenciales y la dependencia jerárquica. No determina, por sí solo, qué pantallas del sistema puede ver esa persona ni a qué datos puede acceder. El puesto es necesario para saber quién es alguien en la clínica; no es suficiente para saber qué puede hacer en el sistema.

1.2. El rol: lo que dice el sistema de permisos

Un rol del sistema es un conjunto de pantallas a las que una persona tiene acceso. No es un cargo ni una categoría: es una lista. El rol «enfermero» en el sistema no describe la profesión de enfermería: describe qué pantallas puede ver alguien que tiene asignado ese rol. Esa lista se define una vez, se aplica a todas las personas con el mismo rol y se modifica cuando cambia la política de acceso de la clínica, no cuando cambia un empleado concreto. El rol es lo que permite que el control de acceso de la clínica funcione de forma predecible.

1.3. Por qué no son lo mismo aunque se llamen igual

El puesto de «médico» puede requerir dos roles distintos en el sistema: uno si el médico solo pasa consulta y otro si además supervisa a residentes. Y el rol de «coordinación de agenda» puede corresponder a puestos muy distintos: una enfermera, un administrativo, un director de centro. Cuando los nombres coinciden —y la tentación es que coincidan— se tiende a pensar que son la misma cosa. No lo son. El puesto cambia cuando cambia el contrato; el rol cambia cuando cambia la política de acceso. Y las dos cosas cambian por razones distintas, en momentos distintos y con consecuencias distintas.

2. Por qué se confunden y qué consecuencias tiene

La confusión no es técnica: es organizativa. Cuando una clínica monta su sistema por primera vez, alguien decide que el médico tiene acceso a todo lo clínico, la recepcionista a la agenda y el administrador a la configuración. Hasta ahí, parece razonable. El problema empieza cuando llega alguien que no encaja limpiamente en ninguna de esas tres cajas, y en lugar de crear un rol nuevo, se le copian los permisos de alguien que «hace algo parecido».

2.1. El efecto cascada: permisos heredados sin revisión

En una clínica sin roles definidos, el método habitual es clonar los permisos de un empleado existente. El nuevo enfermero recibe los permisos del enfermero anterior. Si el anterior tenía acceso a una pantalla que no le correspondía —porque alguien se lo dio para una emergencia y nadie lo quitó—, el nuevo la hereda sin saberlo. Tres rotaciones después, hay media plantilla con acceso a pantallas que no necesitan, y nadie puede explicar cuándo ni por qué se abrieron esos permisos.

2.2. El riesgo legal: permisos que no se pueden justificar

Cuando la auditoría RGPD de la clínica pide la política de accesos, lo que espera encontrar es un documento que diga qué rol tiene acceso a qué y por qué. Si en su lugar encuentra una lista de personas con permisos asignados caso a caso, sin un criterio común, la conclusión del auditor es que la clínica no tiene política de accesos. Y eso, bajo el principio de responsabilidad proactiva del RGPD, es una deficiencia que se sanciona aunque no haya habido ningún incidente.

3. Cuando los permisos se asignan a mano: el problema en la práctica

La asignación a mano no se siente como un problema hasta que lo es. Al principio funciona: pocos empleados, poca rotación, todo el mundo sabe lo que hace. El deterioro es progresivo y silencioso.

3.1. La acumulación invisible de accesos

Un empleado empieza con diez pantallas. Un día necesita una más porque cubre una baja. Se la abren. La baja termina, nadie la cierra. Seis meses después necesita otra por un cambio temporal de función. Se la abren. El cambio deja de ser temporal, pero las dos pantallas anteriores siguen ahí. Al cabo de dos años, ese empleado tiene acceso a veinticinco pantallas de las que solo usa quince. Las otras diez son riesgo sin beneficio: si accede a una de ellas, la clínica no puede explicar por qué la tenía abierta.

3.2. El coste oculto: tiempo del administrador

Cada nueva incorporación requiere que alguien decida qué permisos le da, los configure uno a uno y los compruebe. Cada cambio de función requiere lo mismo. Cada baja requiere que alguien revise qué tenía abierto y lo cierre. En una clínica con veinte empleados y dos rotaciones al año, eso son cuarenta configuraciones manuales que nadie documenta ni audita. Con roles definidos, la misma operación es seleccionar un rol de una lista. La diferencia no es comodidad: es trazabilidad.

3.3. Lo que pasa el día de la inspección

El inspector pregunta: ¿quién tiene acceso a qué? Si la respuesta es un catálogo de roles con una asignación documentada, la inspección avanza. Si la respuesta es «tendría que mirar usuario por usuario», la inspección se detiene ahí. La clínica no puede demostrar que ha aplicado el principio de minimización del acceso porque no hay un criterio general que enseñar, solo decisiones individuales que nadie recuerda.

4. El catálogo de roles como solución estructural

Un catálogo de roles es una lista cerrada de perfiles con sus pantallas asignadas. Se define antes de que llegue el primer empleado, se aplica a todo el que se incorpora y se modifica cuando cambia la política de la clínica, no cuando cambia una persona concreta. Eso es lo que lo convierte en una solución estructural y no en un parche.

4.1. Qué contiene un catálogo bien hecho

Cada rol tiene un nombre, una descripción de para qué sirve y una lista de pantallas a las que da acceso. No tiene un listado de personas: las personas se asignan al rol, no al revés. Cuando el catálogo se diseña bien, cada pantalla del sistema aparece en al menos un rol y ninguna pantalla está en todos los roles. Si una pantalla está en todos, es señal de que no debería requerir permiso. Si una pantalla no está en ninguno, es señal de que falta un rol o de que la pantalla sobra. El catálogo completo de partida está en los roles predefinidos de día cero.

4.2. Cómo se mantiene el catálogo a lo largo del tiempo

El catálogo no es un documento que se escribe una vez y se archiva. Cuando la clínica incorpora un servicio nuevo con pantallas propias, hay que decidir qué roles las ven. Cuando un cambio normativo exige que ciertos datos estén más restringidos, hay que revisar qué roles los tienen. La revisión periódica de permisos incluye esta comprobación: no solo si los empleados tienen el rol correcto, sino si los roles siguen teniendo las pantallas correctas.

5. Cómo se asigna un rol en la práctica

La asignación de un rol debería ser un paso del proceso de alta, no una tarea que se resuelve después. Si el catálogo de roles existe, asignar uno es cuestión de elegirlo de una lista. Si no existe, es una configuración a medida que nadie revisará.

5.1. El momento del alta: rol antes de acceso

El nuevo empleado recibe su usuario, su contraseña y su rol. No recibe un usuario genérico con todos los permisos para «ir configurando sobre la marcha». El rol ya tiene las pantallas definidas, así que desde el primer acceso la persona ve exactamente lo que le corresponde. Si necesita algo más, lo pide; si no necesita algo, ni siquiera sabe que existe. El detalle del proceso está en el alta y la baja de empleado en los permisos de la clínica.

5.2. El cambio de función: sustituir, no acumular

Cuando un empleado cambia de función, su rol cambia con él. El error habitual es añadir el nuevo rol sin quitar el anterior, de modo que la persona acumula accesos de funciones que ya no ejerce. La regla es sustituir: se asigna el nuevo rol y se retira el anterior. Si la nueva función necesita algo del rol anterior, eso se resuelve diseñando el catálogo correctamente, no apilando roles. Lo que implica revocar el acceso cuando cambia el puesto es exactamente eso: dejar solo lo que corresponde.

5.3. La baja: revocar todo, sin cabos sueltos

El día que un empleado deja la clínica, se le retiran todos los roles. No al día siguiente, no cuando el departamento de personal lo tramite: el mismo día. Un acceso activo sin persona detrás es un riesgo que no debería existir ni una hora más de lo necesario. La revocación completa es un paso del proceso de baja, al mismo nivel que la devolución de llaves o la firma del finiquito.

6. El profesional con doble función: dos roles, no un híbrido

En clínicas pequeñas es habitual que una persona ejerza más de una función. El médico que también dirige el centro. La enfermera que también coordina la agenda. El auxiliar que también gestiona el almacén. Cada caso es una combinación de dos roles existentes, no un rol nuevo que haya que inventar.

Un mismo puesto puede necesitar permisos distintos en cada centro: el rol se adapta al acceso, no al cargo del contrato.

6.1. Por qué asignar dos roles en lugar de crear uno especial

Un rol «médico-director» que se crea para una persona concreta es un rol que nadie más va a usar. Cuando esa persona deje de ser directora, el rol queda huérfano en el catálogo. Cuando otra persona asuma la dirección, habrá que crear otro rol a medida. La proliferación de roles ad hoc es el camino directo al mismo desorden que se pretendía evitar. La solución es más simple: el médico que también dirige recibe los roles «médico» y «director de centro», y ve la unión de las pantallas de ambos.

6.2. Qué pasa cuando la doble función termina

Si la combinación se hizo con dos roles, deshacer es retirar uno y dejar el otro. Si se hizo con un rol a medida, deshacer es crear otro rol a medida para la nueva situación. La diferencia entre los dos escenarios es la que separa un sistema mantenible de uno que se deteriora con cada cambio.

6.3. Cuándo sí tiene sentido un rol nuevo

Un rol nuevo tiene sentido cuando la función no se puede cubrir con ninguna combinación de los existentes. Eso ocurre cuando una pantalla nueva no encaja en ningún rol actual, o cuando un cambio normativo obliga a separar un acceso que antes estaba incluido en un rol general. El criterio es que el rol nuevo lo vayan a usar más de una persona, y que resuelva un problema que la combinación de los existentes no resuelve. Si solo lo necesita una persona y solo por un tiempo, la solución es un ajuste temporal, no un rol permanente.

7. Lo que la auditoría ve cuando no hay roles definidos

El control de acceso y la auditoría son dos caras de lo mismo. Sin roles, la auditoría no tiene un patrón contra el que comparar: cada acceso es legítimo o no en función de una decisión individual que nadie documentó.

7.1. Sin roles, no hay política que auditar

El auditor busca una política de accesos: un documento que diga quién debería poder ver qué y por qué. Si no hay roles, no hay política. Lo que hay es un estado de hecho —estos usuarios tienen estos permisos— sin un criterio que lo justifique. La auditoría de accesos del empleado a la historia clínica necesita comparar lo que alguien vio con lo que debería poder ver. Si el «debería» no está escrito, la comparación no existe.

7.2. Cada excepción sin documentar es un hallazgo

Un auditor que encuentra a un administrativo con acceso a la historia clínica pregunta por qué. Si la respuesta es «tiene el rol de recepción, que no incluye esa pantalla, pero se le añadió temporalmente para cubrir una baja y no se retiró», el hallazgo es un defecto de mantenimiento. Si la respuesta es «no lo sabemos», el hallazgo es un defecto de diseño. La diferencia entre los dos es la que separa un problema puntual de un problema sistémico.

8. Cómo migrar de permisos a mano a roles definidos

La migración no tiene por qué ser traumática. Se hace en tres pasos, y el resultado inmediato es un sistema más ordenado, más auditable y más fácil de mantener.

8.1. Inventariar lo que hay: quién tiene acceso a qué

El primer paso es sacar una foto del estado actual. Para cada usuario, qué pantallas tiene abiertas. Para cada pantalla, qué usuarios la ven. Esa foto es la materia prima sobre la que se trabaja. No hace falta que sea perfecta: lo que importa es que exista y que refleje la realidad, no la intención.

8.2. Agrupar: buscar los patrones que ya existen

En la mayoría de los casos, los permisos ya siguen un patrón aunque nadie lo haya formalizado. Los médicos ven las mismas pantallas. Las recepcionistas ven las mismas pantallas. Lo que difiere son las excepciones acumuladas. Agrupar por similitud y etiquetar cada grupo como un rol es el paso que convierte un mosaico en un catálogo. Los permisos que no encajan en ningún grupo son los que hay que evaluar: o son legítimos y justifican un rol nuevo, o son restos de decisiones pasadas que ya no tienen sentido.

8.3. Aplicar los roles y cerrar las excepciones

Una vez definidos los roles, se asignan a cada usuario y se retiran los permisos que sobran. Ese es el momento donde puede haber resistencia: alguien que pierde acceso a una pantalla que usaba aunque no le correspondía. La respuesta no es devolverle el acceso: es preguntarle para qué la usaba. Si la razón es legítima, el rol se ajusta. Si no lo es, el acceso se cierra y la clínica tiene un dato más sobre cómo mejorar su política de acceso.

9. Qué aporta obeliOmed a la separación entre rol y puesto

obeliOmed trae de fábrica la distinción entre puesto y rol resuelta. Lo que sigue es cómo se traduce cada concepto en el software.

9.1. Doce roles con pantallas asignadas desde la instalación

Desde el primer día, el sistema ofrece doce roles que cubren los perfiles habituales de una clínica privada. Cada uno tiene su lista de pantallas asignada, documentada y modificable por el administrador. No hay que diseñar nada desde cero: la clínica arranca con un catálogo funcional y lo ajusta a su realidad.

9.2. Asignación de roles, no de permisos sueltos

El administrador asigna roles a personas, no pantallas a personas. Eso garantiza que dos empleados con la misma función ven lo mismo, y que cualquier cambio en lo que un rol incluye se aplica a todos los que lo tienen. No hay permisos sueltos, no hay configuraciones a medida que nadie recuerda, y no hay el riesgo de que un empleado acumule accesos de funciones que ya no ejerce.

9.3. Restauración de la configuración de fábrica

Si la clínica modifica un rol y después quiere volver al punto de partida, un botón devuelve la configuración original sin tocar nada más. Eso permite experimentar sin riesgo: se puede probar si un enfermero necesita una pantalla nueva, y si no funciona, se deshace. La alternativa —no tocar nada por miedo a romper algo— es lo que lleva a que los permisos se queden congelados en una configuración que ya no refleja la realidad.