La mayoría del software para consultorios trae tres o cuatro roles fijos y espera que su organización coincida con alguno. Los consultorios reales nunca coinciden. Usted tiene un terapeuta que además hace admisiones, una persona de administración que emite facturas pero jamás debe abrir un expediente, un supervisor que supervisa a dos clínicos y a nadie más, y un auditor externo que necesita el historial de actividad por una semana y nunca más. Cuando el software no puede expresar eso, el consultorio termina haciendo lo peligroso: comparte una sesión, o le da permisos de administrador a alguien “temporalmente” y se olvida.
ASL Therapy separa las dos preguntas que casi todos los sistemas mezclan en una sola. ¿Cuál es el puesto de esta persona? ¿Y qué, exactamente, tiene permitido hacer? Responderlas por separado es lo que permite que el modelo de permisos se adapte a su consultorio y no al revés.
Capa uno
El rol base
Diez roles que reflejan cómo se compone realmente un consultorio de terapia: propietario, terapeuta, terapeuta de admisión, agendador, facturación, contabilidad, asistente administrativo, seguridad, auditoría y administrador de plataforma. El rol define el valor predeterminado razonable.
Capa dos
Capacidades por persona
Admisión, alta, supervisión clínica, facturación, administración de cobros y exportación de expedientes se otorgan a individuos, con independencia de su puesto. Dos terapeutas pueden diferir en cada línea.
Capa tres
Visibilidad por cliente
Cada expediente es visible para todo el consultorio, solo para los clínicos asignados, para los supervisores, o únicamente para los propietarios. Siempre gana la regla más estricta que aplique.
Denegar por defecto, y una denegación explícita siempre gana. Un rol que no se reconoce recibe el acceso más estrecho posible y no el más amplio — lo contrario de la falla habitual, en la que un rol no contemplado hereda en silencio permisos de administrador. Si el propietario le niega expresamente una capacidad a alguien, ningún puesto, ninguna relación de supervisión y ningún cambio posterior de rol se la devuelve por su cuenta. Esa sola regla evita la forma más común en que se pudren los sistemas de permisos: excepciones concedidas con prisa que nadie recuerda revocar.
Cada regla se aplica en el servidor, en cada solicitud. Esta es la diferencia entre un sistema de permisos y uno cosmético. Ocultar una opción del menú no es control de acceso; detiene a la persona honesta y a nadie más. Aquí la navegación refleja sus permisos, pero la navegación no es lo que protege el expediente. Un cliente fuera de su visibilidad no se puede abrir ni siquiera con un enlace directo, y la misma verificación se repite en cada nota, reporte, documento, factura y exportación asociada a ese cliente. Auditamos exactamente esto en agosto de 2026, encontramos varias rutas que confiaban en el identificador sin volver a comprobar la visibilidad, y las corregimos todas antes del lanzamiento.
La supervisión es una relación, no un rango. Un supervisor ve el trabajo de las personas concretas que supervisa. De forma predeterminada también puede ver todo el consultorio, porque es lo que la mayoría de los grupos espera el primer día — y un administrador puede desactivarlo con un solo control, limitando a cada supervisor a sus propios clientes más los de sus supervisados. Los clientes marcados como solo-propietario siguen siéndolo en ambos casos, para que un expediente delicado no quede visible para una docena de personas porque alguien recibió un ascenso.
Los cambios son evidencia, no solo configuración. Otorgar una capacidad, negarla, cambiar el rol de alguien, desactivar una cuenta y relajar la regla de aprobación de reportes quedan escritos en el historial a prueba de manipulación, con quién lo hizo y cuándo. Las revisiones de acceso dejan de ser un trabajo de arqueología: la respuesta a “quién podía ver esto, y desde cuándo” ya está registrada. El sistema tampoco permite dejar al consultorio sin propietario ni que el último administrador se desactive a sí mismo.