Control de acceso y roles en la clínica privada: quién ve qué y cómo se revisa

1. Por qué el acceso a los datos clínicos no puede quedarse sin resolver

El dato clínico no es un archivo más. Está protegido por una capa de legislación que incluye la Ley 41/2002, la LOPDGDD y el RGPD, y su tratamiento inadecuado tiene consecuencias que van desde la sanción económica hasta la pérdida de confianza del paciente, que es más difícil de reparar que una multa. Lo que sigue no es teoría: es lo que una clínica necesita tener resuelto antes de que un inspector, un DPO o un paciente pida explicaciones.

1.1. La historia clínica bajo la ley: no es un fichero más

La historia clínica contiene datos de salud, que el RGPD clasifica como categoría especial. Tratarlos requiere una base jurídica reforzada —no basta con el consentimiento genérico de admisión— y un control de acceso que limite quién los ve a quienes los necesitan para el fin asistencial concreto. La Ley 41/2002 añade un matiz que muchas clínicas pasan por alto: el acceso a la historia clínica con fines asistenciales queda limitado a los profesionales que atienden al paciente, no a todos los que trabajan en la clínica. Eso convierte el control de acceso en un requisito legal, no en una buena práctica.

1.2. Lo que mira la AEPD cuando llega una denuncia de acceso

Cuando la AEPD investiga una denuncia por acceso indebido a datos de salud, el primer documento que pide es el registro de accesos. Si no existe o está incompleto, la instrucción parte de una presunción desfavorable. Si existe, lo que mira es si había un control previo que limitara el acceso por rol, si ese control estaba documentado y si se revisaba periódicamente. No basta con tener permisos: hay que demostrar que alguien los diseñó, que alguien los revisa y que la auditoría de accesos de los empleados a la historia clínica está operativa, no solo prevista.

1.3. El coste real de tener los permisos abiertos de más

El riesgo no siempre es una multa. A menudo es algo más silencioso: un empleado que accede a la historia de un conocido, un administrativo que ve un diagnóstico que no debería haber visto, un técnico externo cuyo acceso temporal no se cerró. Cada uno de esos casos es una brecha de seguridad que la clínica tiene que gestionar ante la AEPD en menos de 72 horas si afecta a datos de salud. El coste de tener los permisos bien desde el principio es bajo comparado con el coste de gestionar un incidente cuando ya ha pasado.

2. Qué es un rol y por qué no es lo mismo que un puesto de trabajo

La confusión más frecuente al montar los permisos de una clínica es tratar el puesto de trabajo como si fuera un rol. No lo es. El puesto es lo que dice el contrato laboral; el rol es lo que el sistema le permite hacer. Y una clínica donde cada puesto tiene su propio juego de permisos personalizados es una clínica que no escala: cada alta nueva exige reinventar los accesos, y cada cambio de función deja permisos huérfanos que nadie revisa. La diferencia completa está en por qué confundir el rol con el puesto desordena los permisos de la clínica.

2.1. El organigrama y el mapa de permisos son dos cosas distintas

El organigrama refleja la jerarquía de mando: quién reporta a quién. El mapa de permisos refleja quién necesita acceder a qué dato para hacer su trabajo. Un director médico puede no necesitar acceso a la facturación, y un administrativo puede necesitar acceso a la agenda de todos los profesionales sin ver ni una nota clínica. Cuando la clínica calca los permisos del organigrama, el resultado es un sistema donde los jefes ven todo y los demás ven poco, y eso no responde a la pregunta que importa: quién necesita qué para trabajar.

2.2. Un puesto cambia y los permisos no se mueven solos

El caso más habitual es el empleado que cambia de función dentro de la clínica: pasa de recepción a coordinación, de enfermería a gestión, de una consulta a otra. Su puesto cambia, pero sus permisos anteriores siguen abiertos si nadie los revoca. Es el hueco más común en el control de acceso de las clínicas, y el más difícil de detectar sin una revisión periódica, porque no genera ningún error ni ninguna alerta. El detalle de cómo se cierra ese hueco está en revocar el acceso cuando alguien cambia de puesto.

2.3. El usuario sin rol: la cuenta que nadie terminó de montar

Un usuario sin rol asignado no ve nada, pero sigue existiendo en el sistema. Es una cuenta abierta sin permisos, lo que significa que alguien la creó y no completó el proceso, o que alguien le retiró todos los roles y no la desactivó. Cualquiera de las dos cosas es un problema de higiene que conviene detectar antes de que lo detecte una auditoría. Lo que pasa cuando esa cuenta existe y qué debería pasar está en el usuario sin rol en el software clínico.

3. Los doce roles del día cero y por qué importa no arrancar de cero

Hay clínicas que instalan su software y se encuentran un sistema en blanco: sin roles, sin permisos, sin una propuesta de partida. Cada persona que entra necesita que alguien le monte los accesos a mano, y ese alguien improvisa porque no hay plantilla. El resultado son permisos desiguales, inconsistentes y difíciles de auditar. La alternativa es un software que arranque con un conjunto de roles funcionales desde el primer día, pensados para cubrir los perfiles habituales de una clínica privada. Qué incluyen y cómo se ajustan está en los roles predefinidos del día cero en el software clínico.

3.1. Qué cubren los roles que vienen de serie

Un conjunto de roles del día cero cubre los perfiles que cualquier clínica necesita el primer día: el médico que pasa consulta, el personal de enfermería que prepara al paciente, el óptico que hace la refracción, el administrativo que gestiona la agenda, el responsable de facturación que cierra cobros, el director médico que supervisa y el DPO que audita. No son doce cargos inventados: son doce combinaciones de pantallas que responden a lo que cada perfil necesita ver —y no ver— para trabajar. Cuando esos roles no existen de partida, la primera semana de la clínica se gasta en decidir quién ve qué, y la decisión se toma con prisas y sin criterio.

3.2. Un rol es un punto de partida, no una camisa de fuerza

El rol predefinido no es una imposición: es una propuesta que funciona tal cual para la mayoría de las clínicas y que se puede ajustar para las que necesitan algo distinto. Lo habitual es que el administrador clínico revise los roles del día cero, quite un acceso que sobra, añada otro que falta y deje el sistema listo en menos de una hora. Lo que no debería hacer es empezar de cero, porque el tiempo que se gasta en diseñar doce roles desde una pantalla en blanco es tiempo que ya se invirtió en una propuesta que funciona.

3.3. Lo que pasa cuando la clínica arranca sin roles

Sin roles predefinidos, los permisos se asignan uno a uno, persona a persona. Cada alta nueva es una decisión que toma alguien distinto, y cada decisión acumula una pequeña desviación respecto a la anterior. En pocas semanas, dos personas con el mismo cargo tienen accesos diferentes, y nadie sabe cuál de las dos configuraciones es la correcta. Auditar eso después cuesta más que haberlo hecho bien desde el principio.

4. Qué ve cada persona al abrir la ficha del paciente

El control de acceso no es solo decidir quién entra al sistema: es decidir qué ve cada persona una vez dentro. Un médico y un administrativo pueden abrir la misma ficha, pero lo que necesitan ver es distinto, y lo que la ley les permite ver también. Qué ve recepción al abrir la ficha de un paciente —y qué no debería ver— es una pregunta que toda clínica debería haberse hecho antes de dar acceso a nadie. El detalle está en qué ve el administrativo al abrir la ficha del paciente.

4.1. Lo que recepción necesita y lo que no debería ver

Recepción necesita abrir la ficha para identificar al paciente, comprobar su cita, verificar los datos de contacto y gestionar el cobro si corresponde. No necesita ver el diagnóstico, ni las notas clínicas, ni los resultados de las pruebas. Pero si el sistema muestra todo en la misma pantalla, recepción lo ve todo, y la clínica está incumpliendo el principio de minimización del RGPD. La solución no es quitar acceso a recepción: es separar los datos que necesita de los que no, y eso se hace con pantallas distintas, no con buenas intenciones.

4.2. Cuando un dato necesita menos ojos que los que abren la pantalla

Hay datos que necesitan un acceso más restringido que el de la pantalla donde viven. Un campo de antecedentes psiquiátricos, una nota sobre una ETS, un dato de filiación que no debería ver un estudiante en rotación. La solución más limpia es dar a ese dato su propia pantalla con su propio permiso, de forma que solo lo ve quien tiene acceso explícito. No es ocultar: es gobernar el acceso al nivel de detalle que el dato exige. La lógica completa de por qué funciona está en separar el dato restringido en su propia pantalla.

5. Exportar y borrar: los dos permisos con más consecuencias

No todos los permisos tienen el mismo peso. Abrir una pantalla tiene un riesgo contenido; sacar datos fuera del sistema o eliminarlos tiene un riesgo que no se revierte. Por eso exportar y borrar son los dos permisos que más cuidado necesitan al asignar, y los dos que más justificación deberían exigir cuando se usan.

No todos los permisos pesan lo mismo: exportar y borrar son los dos que no tienen marcha atrás.

5.1. Quién puede sacar datos fuera del sistema

Exportar datos clínicos es sacar información protegida del perímetro del sistema. Una vez fuera, el dato deja de estar bajo el control de acceso de la clínica y queda sujeto a lo que haga la persona que lo tiene. No todo el que necesita consultar un dato necesita poder llevárselo, y la distinción entre consultar y exportar debería estar reflejada en los permisos. Qué controles necesita una clínica y quién debería tener ese permiso está en exportar datos clínicos: quién puede hacerlo.

5.2. Borrar un dato clínico: lo que la ley dice sobre los plazos

Borrar un dato de la historia clínica no es pulsar un botón. La ley establece plazos mínimos de conservación —cinco años desde el alta del proceso asistencial, según la Ley 41/2002, y hasta quince según la normativa autonómica— y cualquier eliminación antes de ese plazo es una infracción. Además, la eliminación debe ser trazable: quién la autorizó, cuándo se ejecutó y por qué motivo. Los plazos, los matices y lo que implica usarlo están en borrar datos de la historia clínica: cuándo se puede y cuándo no y en quién tiene el permiso para hacerlo.

6. Un profesional, dos centros: permisos que viajan

Una clínica con una sola sede resuelve los permisos una vez y no vuelve a tocarlos salvo por altas y bajas. Pero en una red de centros, un profesional puede trabajar en más de una sede, y sus permisos tienen que acompañarlo sin abrirle la puerta a datos de centros donde no está prestando servicio. Es un escenario cada vez más habitual, sobre todo en especialidades donde el mismo oftalmólogo o el mismo cirujano rota entre dos o tres consultorios. Cómo funcionan esos permisos está en permisos y acceso cuando el médico trabaja en dos centros.

6.1. El especialista que trabaja en más de una sede

El caso estándar es un médico que pasa consulta dos días en un centro y tres en otro. Necesita ver la historia de los pacientes que atiende en cada sede, pero no necesariamente la de todos los pacientes de todas las sedes. Dependiendo de cómo esté configurado el multicentro, sus permisos pueden viajar con él o quedarse en cada sitio. Lo primero es más operativo para el profesional; lo segundo es más seguro para los datos que no le corresponden. El equilibrio depende de la estructura de la clínica y del tipo de dato.

6.2. Ver la agenda de otro centro: cuándo tiene sentido y cuándo abre una puerta

En una red de clínicas, poder consultar si hay hueco en otra sede para derivar a un paciente es útil. Pero ver la agenda completa de otro centro —con los nombres de los pacientes, las horas y los profesionales— es un nivel de acceso que hay que justificar. La visibilidad entre centros no debería ser todo o nada: debería responder a lo que cada persona necesita ver para trabajar, igual que el acceso a la historia clínica. Cuándo tiene sentido abrirla y qué criterios aplicar está en la visibilidad de la agenda entre centros.

7. El ciclo de vida de un permiso: alta, cambio de puesto y baja

Un permiso no es algo que se asigna y se olvida. Tiene un ciclo: se abre cuando alguien entra, se revisa cuando cambia de función, y se cierra cuando se va. Las tres fases importan, pero la que más clínicas descuidan es la del medio, porque no genera ningún evento visible. El mapa completo está en el ciclo completo de permisos del empleado en la clínica.

7.1. El primer día y lo que se abre con criterio

Cuando un empleado se incorpora, alguien le crea una cuenta y le asigna un rol. Si la clínica tiene roles predefinidos, el proceso es rápido: se elige el rol que corresponde al perfil, se ajusta si hace falta y el empleado trabaja desde el primer día con los permisos que necesita. Si no los tiene, alguien improvisa, y la improvisación se queda como configuración permanente. El primer día es cuando más importa que los roles estén bien montados, porque la urgencia de que la persona trabaje compite con el rigor de que sus permisos sean los adecuados.

7.2. El proveedor externo que entra una tarde

Un técnico de mantenimiento que necesita acceder al sistema para una actualización o una reparación es un caso especial: necesita un acceso real, pero temporal y acotado. Se le abre un usuario con un rol limitado, se registra cuándo entra y cuándo sale, y se cierra la cuenta cuando termina. Si el acceso se abre con un usuario genérico compartido, la trazabilidad se pierde y la clínica no puede demostrar quién hizo qué. El procedimiento completo está en el acceso temporal del técnico de mantenimiento.

7.3. El último día y lo que nadie revoca

Cuando un empleado deja la clínica, su cuenta debería desactivarse el mismo día. En la práctica, las cuentas de empleados que se fueron siguen activas semanas o meses después, porque nadie las revisó y no generan ningún error. Un usuario inactivo con permisos abiertos es un riesgo dormido: no pasa nada hasta que pasa, y cuando pasa, la clínica tiene que explicar por qué había una cuenta activa de alguien que ya no trabaja allí.

8. Auditar los accesos: cómo saber quién vio qué

Montar los permisos es la mitad del trabajo. La otra mitad es comprobar que funcionan: que quien debería ver un dato lo ve, que quien no debería verlo no lo ve, y que hay una traza que lo demuestra. La auditoría de accesos no es un ejercicio anual que se hace porque lo pide el DPO: es el mecanismo que convierte los permisos en un sistema verificable. Cómo se hace con la historia clínica del empleado está en la auditoría de accesos del empleado según el RGPD y la lista completa de puntos de control en el checklist de auditoría RGPD para clínicas.

El registro de accesos responde a una sola pregunta: quién vio qué, cuándo y desde dónde.

8.1. El registro de accesos y lo que tiene que contener

El registro de accesos es el documento que responde a la pregunta «quién vio qué, cuándo y desde dónde». Tiene que contener, como mínimo, la identidad del usuario, la fecha y hora, la pantalla o dato al que accedió y la acción que realizó. Si además incluye la dirección IP y el centro desde el que se conectó, la traza es más completa. Cuando el DPO o la AEPD pide este registro, la clínica tiene que poder generarlo sin necesidad de reconstruirlo a posteriori. Los campos exactos están en el informe de accesos para el DPO.

8.2. La revisión periódica que nadie programa

La revisión de permisos no es algo que se hace cuando pasa algo: se hace periódicamente, para detectar los permisos que sobran antes de que generen un incidente. Lo habitual es revisarlos cada trimestre o cada semestre, comprobando que cada usuario tiene los accesos que necesita para su función actual y ninguno más. Es un ejercicio simple —un listado de usuarios con sus roles, revisado contra el organigrama vigente— pero que exige que alguien lo tenga asignado y lo haga de verdad. La frecuencia y el método están en la revisión periódica de permisos.

8.3. Cuando la traza revela un acceso indebido

A veces la auditoría muestra un acceso que no debería haberse producido: un empleado que abrió una historia que no le correspondía, un acceso fuera de horario sin justificación, una consulta masiva de fichas sin relación asistencial. Descubrirlo no es el final: es el principio de un protocolo que incluye la verificación del acceso, la evaluación de la gravedad, la comunicación al DPO y, si procede, la notificación a la AEPD dentro del plazo de 72 horas. Lo que hay que hacer paso a paso está en qué hacer cuando la traza revela un acceso indebido.

9. Qué aporta obeliOmed

obeliOmed está diseñado para que el control de acceso funcione desde el día cero, sin que la clínica tenga que diseñar permisos desde una pantalla en blanco ni contratar a un consultor para montarlos.

9.1. Doce roles funcionales desde la instalación

Al instalar obeliOmed, el sistema crea doce roles que cubren los perfiles habituales de una clínica privada: médico, médico jefe, enfermería, óptico-optometrista, auxiliar clínico, recepción, administrador clínico, director médico, DPO, facturación, auditor LOPD y sistema. Cada uno lleva preconfigurados los accesos a las pantallas que necesita y ninguno más. El administrador clínico puede ajustarlos desde la interfaz sin tocar código, y un botón de restauración permite volver a los valores de fábrica si algo se desconfigura.

9.2. El dato restringido tiene su propia pantalla

Cuando un dato necesita un nivel de acceso más estricto que el de la pantalla donde se consulta habitualmente, obeliOmed le da su propia pantalla con su propio permiso. De esa forma, el acceso se gobierna al nivel del dato, no al nivel de toda la ficha. No es un campo oculto: es una pantalla distinta que solo ve quien tiene el rol adecuado. Eso permite que recepción abra la ficha sin ver la nota clínica, y que un profesional en rotación vea lo asistencial sin acceder a datos administrativos que no le corresponden.

9.3. Trazabilidad completa: quién accedió, cuándo y desde dónde

obeliOmed registra cada acceso a un dato clínico: qué usuario, a qué pantalla, qué acción realizó, cuándo y desde qué centro. Ese registro alimenta el informe que necesita el DPO, la revisión periódica de permisos y el protocolo de respuesta ante un acceso indebido. La trazabilidad no se configura ni se activa: está siempre encendida, para que la clínica no dependa de que alguien la haya activado cuando la necesite.