¿Qué roles necesita un sistema para una clínica médica?

Un rol no debe ser una contraseña compartida

La primera regla de una clínica multiusuario es que cada persona use su propia identidad.

No conviene crear cuentas genéricas como recepción, doctor1, administración o una misma contraseña para médicos y recepción.

Una cuenta compartida hace difícil retirar acceso a una sola persona y dificulta atribuir quién realizó una acción.

El rol responde otra pregunta: qué puede hacer esa identidad dentro de la organización.

Los tres roles públicos de VITALINK

El modelo actual de Clínica distingue tres roles públicos.

Administrador de clínica

Gestiona la organización.

Puede encargarse de superficies como:

• miembros e invitaciones;
• roles;
• sedes o establecimientos;
• configuración organizacional;
• marca y otros datos administrativos.

Este rol no concede acceso clínico por sí mismo.

Si la persona administradora también atiende pacientes, necesita además el rol Médico y la identidad profesional correspondiente. Por eso una misma persona puede tener más de un rol sin convertir todos los administradores en médicos.

Médico

Es el rol que habilita capacidad clínica.

Aun así, “es médico de la clínica” no debe traducirse como “puede abrir todos los expedientes de la clínica”.

El acceso al contenido clínico sigue necesitando:

• identidad profesional;
• contexto de clínica y sede cuando corresponda;
• acceso al paciente;
• y el alcance que corresponda al caso.

El sistema puede distinguir acceso completo al paciente de acceso parcial a consultas concretas. Un permiso parcial no debe escalar silenciosamente a poder modificar todo el expediente.

Asistente

VITALINK llama Asistente al rol operativo no clínico.

Puede participar en tareas como agenda y coordinación cuando la clínica las habilita, pero el rol Asistente no da acceso al contenido clínico.

Eso permite que recepción pueda trabajar con una cita sin necesitar historia clínica, diagnósticos, recetas o notas.

La implementación de agenda de Clínica utiliza referencias opacas para operar pacientes desde superficies no clínicas y evita exponer identificadores clínicos directos o campos como CURP, motivo clínico y notas en el contrato de scheduling.

¿Qué puede hacer un administrador de clínica en un ECE?

Un administrador debería gestionar la organización, no obtener privilegios clínicos como efecto secundario.

Ejemplos de tareas administrativas razonables:

• invitar o retirar integrantes;
• asignar roles;
• administrar sedes;
• gestionar identidad visual y configuración de clínica;
• revisar superficies operativas que no contienen expediente clínico;
• coordinar agenda cuando el producto lo permite.

Lo que no debe ocurrir es:

“Como soy administrador, puedo abrir cualquier historia clínica.”

En VITALINK un perfil con solo clinic_admin se trata como no clínico. Para atender y abrir contenido clínico necesita también rol Médico y el scope correspondiente.

¿Qué puede hacer una secretaria o recepcionista?

En el lenguaje del producto, esa función se modela como Asistente.

La pregunta no debería ser “¿la secretaria puede entrar al sistema?”, sino “¿qué información necesita para hacer su trabajo?”.

Para coordinación de citas puede ser suficiente conocer:

• nombre operativo mostrado para agenda;
• teléfono o correo cuando el flujo lo requiere;
• horario;
• profesional;
• sede;
• estado de la cita.

No necesita, por ese solo trabajo:

• historia clínica;
• diagnósticos;
• CURP;
• notas de consulta;
• receta;
• resultados clínicos.

La arquitectura debería permitir hacer agenda sin ensanchar el acceso clínico.

Cómo aislar pacientes de médicos distintos dentro de una clínica

El aislamiento correcto no consiste en crear una base de datos distinta por médico ni en confiar únicamente en la interfaz.

Debe existir una decisión de autorización en el backend para cada acceso clínico.

El modelo actual de VITALINK separa:

• pertenencia a la clínica;
• rol Médico;
• contexto de clínica/sede;
• concesión activa sobre el paciente;
• alcance completo o parcial.

Si no existe una concesión activa, el acceso falla cerrado.

Un alcance parcial puede limitarse a consultas concretas. Para una operación que modifica al paciente de forma general, como una actualización patient-wide, VITALINK exige acceso completo; un grant parcial no se amplía automáticamente.

Esto evita que un médico obtenga el resto del historial solo porque recibió acceso a una consulta concreta.

Ser compañeros de clínica no debe compartir todos los expedientes automáticamente

Una organización puede necesitar colaboración clínica, pero la membresía administrativa no es una base suficiente para abrir todo el archivo.

Una regla útil es:

compartir únicamente cuando existe una finalidad asistencial u operativa válida, la base de tratamiento correspondiente y un alcance proporcional a esa finalidad.

Ejemplos donde puede tener sentido habilitar acceso clínico a otro médico:

• interconsulta;
• atención coordinada;
• sustitución o continuidad de tratamiento;
• atención por otro profesional de la misma organización cuando el flujo y la base aplicable lo permiten.

Ejemplos donde no basta la mera pertenencia:

• “trabajamos en la misma clínica”;
• “soy el administrador”;
• “quiero revisar por si acaso”;
• “recepción necesita saber de qué se habló”.

La LFPDPPP obliga a proteger los datos sensibles de salud con medidas administrativas, técnicas y físicas acordes con el riesgo. Limitar acceso por persona y finalidad es parte de una arquitectura coherente con esa obligación; no debe convertirse en un acceso global por comodidad.

Qué evidencia debería acompañar una compartición

Una compartición sensible debe ser explicable después.

El contrato de compartición clínica diseñado en VITALINK contempla evidencia como:

• versión del aviso aplicable;
• hash de esa versión;
• base jurídica declarada;
• responsable y encargado de referencia;
• finalidad;
• alcance;
• método;
• titular o representante;
• clínica y sede;
• autor de la acción;
• revocación con motivo.

Además, la evidencia y los eventos de compartición se mantienen fuera de lectura directa del cliente.

Ese contrato no debe presentarse como “certifica el cumplimiento legal”: sirve para registrar y limitar una decisión que sigue necesitando una base correcta.

La compartición self-service no se presenta hoy como función general disponible

VITALINK ya tiene el contrato técnico para concesiones y revocaciones clínicas, pero la superficie self-service de compartición de pacientes permanece detrás de un feature flag deshabilitado por defecto y no aparece como una función general para clientes.

Por eso esta guía describe:

• el modelo vigente de roles y aislamiento;
• el contrato de acceso que protege operaciones clínicas;
• y el criterio que debe seguir cualquier futura superficie de compartición.

No afirmamos que hoy exista un botón público de “compartir expediente con otro médico” disponible para todas las clínicas.

Cómo documentar el acceso de otro médico a un paciente

El acceso clínico de otro médico no debería quedar explicado solo por “pertenece a la clínica”.

Un registro defendible debe poder responder:

• quién recibió acceso;
• a qué paciente o consultas;
• con qué alcance;
• desde qué clínica/sede;
• con qué finalidad;
• qué base/evidencia respalda la decisión;
• quién lo concedió;
• cuándo empezó;
• cuándo se revocó y por qué.

VITALINK modela las concesiones clínicas separadas de la membresía. El contrato técnico contempla alcance completo o parcial y evidencia de compartición. La superficie self-service general sigue deshabilitada por defecto, así que esta estructura describe el control existente y el criterio de una futura UI; no un botón universal disponible hoy.

Altas, cambios y bajas de personal clínico

Un onboarding correcto no termina al enviar una invitación.

Alta

1. identidad individual;
2. invitación nominativa;
3. rol o roles mínimos;
4. sedes necesarias;
5. identidad profesional cuando el rol sea Médico;
6. acceso clínico únicamente cuando exista una finalidad concreta.

Cambio de función

No acumules permisos antiguos. Sustituye roles y sedes por el alcance vigente y revisa grants clínicos existentes.

Baja

• revoca membresía/roles;
• retira sedes asignadas;
• revoca concesiones de pacientes que ya no procedan;
• conserva auditoría y autoría histórica;
• no reutilices la cuenta para la persona sustituta.

La salida de un profesional nunca debe reescribir quién firmó una nota anterior.

Permisos por sede

La sede es un scope operativo adicional, no un rol.

En el modelo actual de VITALINK, una membresía puede tener establishmentIds. El backend comprueba esas asignaciones para superficies de agenda y contexto de Clínica; además, una asignación de sede no concede por sí sola roles ni acceso clínico.

Eso permite configuraciones como:

• Asistente solo en sede Centro;
• Médico en Centro y Sur;
• Administrador organizacional sin convertirlo en médico;
• mismo rol, distinto alcance de sedes.

La combinación correcta es:

identidad + rol + sede + acceso al paciente cuando sea clínico.

¿Y permisos por especialidad?

“Cardiología” o “Pediatría” describen una capacidad/profesión, pero no son por sí solas una buena regla de autorización.

Dos cardiólogos de la misma clínica no necesitan automáticamente ver los mismos pacientes; y un profesional de otra especialidad puede necesitar acceso legítimo por interconsulta.

A septiembre de 2026, VITALINK no publica una capa de permisos clínicos basada en especialidad. La autorización vigente se resuelve por identidad, rol, sede/contexto y concesión sobre el paciente.

Si una organización necesita reglas adicionales por servicio o especialidad, deberían añadirse como una política explícita y auditable, sin sustituir el control paciente/contexto por una etiqueta profesional.

Cómo retirar acceso cuando cambia el equipo

Un sistema de roles debe contemplar el final de la relación, no solo la invitación.

Cuando una persona cambia de función o sale de la clínica:

1. retirar o sustituir sus roles;
2. revocar membresía cuando corresponda;
3. revisar sedes asignadas;
4. revocar accesos clínicos que ya no tengan finalidad;
5. evitar conservar contraseñas o cuentas genéricas compartidas;
6. mantener trazabilidad de lo ocurrido mientras el acceso estuvo vigente.

Eliminar a una persona del equipo no debería borrar el historial clínico ni alterar quién firmó documentos anteriores.

Qué configuración recomendamos para una clínica pequeña

Un ejemplo simple:

No uses esta tabla como plantilla legal universal. Sirve para ilustrar una idea: los permisos siguen la función, no el cargo en una tarjeta de presentación.

Qué probar antes de contratar un sistema multiusuario

Crea tres cuentas de prueba:

1. administrador no médico;
2. médico;
3. asistente.

Después verifica:

• ¿el administrador puede gestionar miembros sin abrir historias clínicas?
• ¿el asistente puede manejar agenda sin ver diagnósticos?
• ¿un médico puede acceder solo a pacientes/contextos autorizados?
• ¿un permiso parcial permanece parcial?
• ¿puedes retirar acceso sin borrar documentos?
• ¿cada acción conserva identidad individual?

Si la única forma de operar una clínica es dar a todos la misma contraseña o acceso completo a todos los pacientes, el modelo de permisos no está separando realmente las responsabilidades.