Módulo 01 · Acceso y gestión de usuarios
Última actualización: 14 de noviembre de 2026.
Documento funcional para validación con usuarios. Se presentan comportamientos esperados y reglas en lenguaje claro.
Contexto funcional vigente
Sección titulada «Contexto funcional vigente»El MVP se desarrolla en plataforma web. Salud 365 presenta la experiencia del usuario y coordina las operaciones; Elite Global Doctors (EGD) es el core clínico. Las capacidades concretas de sus servicios e interfaces aún requieren validación técnica.
El titular que contrata y paga puede ser distinto del paciente; los pacientes dependientes deben estar vinculados y autorizados. Los usuarios, pacientes y médicos requieren registro y correspondencia de identidad entre Salud 365 y EGD.
Descripción funcional y procesos
Sección titulada «Descripción funcional y procesos»Especificación de Requerimientos Funcionales
Sección titulada «Especificación de Requerimientos Funcionales»Objetivo y alcance
Sección titulada «Objetivo y alcance»Definir el comportamiento funcional del registro, autenticación, recuperación de acceso, roles, sesiones y sincronización de usuarios entre Salud 365 y Elite Global Doctors (EGD). El documento es una propuesta de especificación para revisión; distingue acuerdos documentados de reglas por confirmar.
Bases y decisiones vigentes
Sección titulada «Bases y decisiones vigentes»Actores y conceptos
Sección titulada «Actores y conceptos»RF-01-001 · Registro de cuenta
Sección titulada «RF-01-001 · Registro de cuenta»Objetivo: Permitir el autorregistro exclusivamente de una cuenta TITULAR(Perfil), independiente de la condición de paciente, para contratar servicios y gestionar pacientes asociados.
Precondiciones: No existe sesión autenticada.
Flujo principal (propuesto):
-
El usuario selecciona Crear cuenta.
-
Ingresa correo electrónico y celular conforme a los campos definidos para el registro; establece su contraseña según la política de seguridad: mínimo 10 caracteres, alfanumérico, al menos una letra, al menos número, y al menos un carácter especial.
-
Salud 365 verifica formato y existencia previa de la cuenta en Salud365.
-
La cuenta queda pendiente de verificación. El sistema ejecuta la verificación del correo electrónico según el mecanismo OTP que apruebe Salud 365.
-
Con el correo verificado, Salud 365 activa la cuenta TITULAR y notifica por correo la BIENVENIDA a la aplicación.
Alternativas / excepciones: Correo existente: ofrecer acceso o recuperación sin divulgar datos innecesarios.
Validaciones: Nombres y Apellidos;Documento de identidad(Tipo y Número); fecha nacimiento; genero( Femenino, Masculino, Otros);dirección(opcional);Correo válido y normalizado; celular según formato y país(maximo dos números); contraseña conforme a política de seguridad; evitar duplicados; impedir la autoasignación de los perfiles MÉDICO y ADMINISTRADOR; no crear ficha clínica automáticamente por ser titular; bloquear uso funcional sin confirmación EGD. La cuenta se activa después de verificar el correo electrónico.
Integración / datos: Alta en Salud 365 . Las credenciales se gestionarán de forma segura.
Criterios de aceptación: cuenta TITULAR única; cuenta pendiente hasta verificar el correo; cuenta activa después de verificarlo; envío de bienvenida por correo.
Referencias de trazabilidad (vinculación preliminar): FL-01-001 | INT-00 | Checklist EGD: Sin referencia registrada.
RF-01-002 · Autenticación mediante correo y contraseña
Sección titulada «RF-01-002 · Autenticación mediante correo y contraseña»Objetivo: Permitir ingreso seguro al frontend.
Precondiciones: cuenta registrada y activa; una cuenta pendiente o inactiva no puede ingresar.
Flujo principal (propuesto):
-
El usuario ingresa su correo electrónico y contraseña.
-
Salud 365 valida las credenciales mediante el mecanismo seguro de autenticación definido.
-
Se valida que la cuenta esté ACTIVA; de lo contrario se deniega el acceso funcional.
-
Se crea una sesión con permisos apropiados segun el rol ( TITULAR,MEDICO,ADMINISTRADOR) y se muestra el dashboard inicial según rol:
-
TITULAR: Ver RF 01-003, RF 01-004,RF 01-005, RF-02-001,RF-02-002, RF-02-003, RF-08-008, RF-09-009, RF-10-009
-
MEDICO:Ver RF 01-003, RF 01-004,RF 01-005,RF-03-003,RF-03-004
-
ADMINISTRADOR:Ver RF 01-003, RF 01-004,RF 01-005,RF-03-001,RF-03-002,RF-03-008, RF-08-001, RF-09-001, RF-10-001
Alternativas / excepciones: Credenciales incorrectas: denegar ingreso sin revelar datos sensibles..
Validaciones: verificación segura de contraseña; limitación de intentos (máximo 3); bloqueo de cuenta y desbloqueo después de un tiempo parametrizado (60 segundos), ambos notificados únicamente por correo electrónico; protección ante fuerza bruta y control de sesiones (tiempo propuesto por sesión: de 5 a 15 minutos por inactividad).
Criterios de aceptación: Un usuario verificado accede; un intento inválido no crea sesión; los errores se registran sin exponer datos sensibles.
Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.
RF-01-003 · Recuperación de acceso
Sección titulada «RF-01-003 · Recuperación de acceso»Objetivo: Permitir restablecer el acceso sin comprometer identidad.
Precondiciones: El usuario declara que no puede ingresar.
Flujo principal (propuesto):
-
Selecciona Recuperar acceso.
-
Indica correo registrado.
-
El sistema envía un código de verificación de 6 dígitos por correo, sin confirmar públicamente la existencia de la cuenta.
-
Tras validar el código, permite establecer una nueva contraseña e invalida todas las sesiones anteriores. El mismo mecanismo de recuperación corresponde a TITULAR, MÉDICO y ADMINISTRADOR.
Alternativas / excepciones: código vencido (vigencia de 2 minutos); si se genera otro código, el anterior se cancela; tras 3 intentos incorrectos, el código se invalida y debe iniciarse un nuevo proceso seguro.
Validaciones: verificación de correo; código de 6 dígitos con vigencia de 2 minutos; invalidación tras 3 intentos incorrectos; un código nuevo reemplaza al anterior; no revelar si una cuenta existe.
Criterios de aceptación: Se recupera el acceso con verificación válida y no mediante datos de terceros.
Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.
RF-01-004 · Roles, permisos y sesiones
Sección titulada «RF-01-004 · Roles, permisos y sesiones»Objetivo: Aplicar permisos según los tres perfiles definidos: TITULAR ,MEDICO y ADMINISTRADOR. El rol ADMINISTRADOR solo mediante alta interna autorizada.
Precondiciones: Usuario autenticado.
Flujo principal (propuesto):
-
Se identifica el único rol asignado a la cuenta: TITULAR (autorregistro), MÉDICO o ADMINISTRADOR (alta interna autorizada).
-
Se cargan las funciones autorizadas para ese rol.
-
Se valida autorización también en el backend para cada operación.
-
Se permite cerrar sesión y se invalida la sesión según la política definida.
Alternativas / excepciones: Acceso a recurso no autorizado: denegar y registrar evento. Sesión vencida: solicitar nueva autenticación.
Validaciones: Separar usuario pagador(titular) , paciente y administrador; la relación con dependientes no concede acceso clínico automático. Una cuenta se le asigna un unico rol.
Criterios de aceptación: El usuario puede abrir solamente información de los paciente dependientes y de el mismo, siempre que EGD valide la visualización de su información clínica.
Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.
RF-01-005 · Consulta y actualización del perfil
Sección titulada «RF-01-005 · Consulta y actualización del perfil»Objetivo: Permitir al titular consultar y corregir datos administrativos para los 3 roles.
Precondiciones: Sesión activa y autorización.
Flujo principal (propuesto):
-
El usuario abre Mi perfil.
-
Para el TITULAR y ADMINISTRADOR, el sistema presenta datos autorizados. Por ejemplo: nombres y apellidos; documento de identidad (tipo y número); fecha de nacimiento; género (Femenino, Masculino, Otros); dirección (opcional); correo válido y normalizado; celular según formato y país (máximo dos números). Forma de pago. El correo se presenta como dato de lectura. El TITULAR dispone también de su fotografía de perfil.
-
Para el MEDICO , el sistema presentara datos autorizados, Por Ejemplo
| Campo | ¿Editable? | Recomendación funcional |
|---|---|---|
| Nombres | No | Datos de identidad registrados y validados. |
| Apellido paterno | No | Solo lectura. |
| Apellido materno | No | Solo lectura. |
| Tipo de documento | No | No permitir modificación directa. |
| Número de documento | No | No permitir modificación directa. |
| Fecha de nacimiento | No | Solo lectura; corrección mediante administración. |
| Género | Sí | Permitir actualizar según catálogo definido. |
| Fotografía de perfil | Sí | Permitir cargar, reemplazar o eliminar. |
| Correo electrónico | No | Mostrar únicamente, sin edición. |
| Contraseña | No directamente | Utilizar la recuperación mediante dígitos enviados al correo; no editar la contraseña como un dato administrativo del perfil. |
| Celular principal | Sí | Validar código de país y formato. |
| Celular secundario | Sí | Opcional; máximo dos números en total. |
| Dirección | Sí | Opcional, si se requiere administrativamente. |
| País de residencia | Sí, condicionado | Si no afecta la habilitación profesional. |
| Número de colegiatura | No | Dato profesional validado. |
| Especialidad médica | No | Administrada por EGD. |
| Años de experiencia | No | Recomiendo que EGD lo administre. |
| Descripción profesional | Sí, condicionado | Editable si EGD permite actualizarla y se define su validación. |
| Idiomas de atención | Sí, condicionado | Si EGD admite actualizar esta información. |
| Disponibilidad médica | No | Gestionada exclusivamente por EGD. |
| Estado de habilitación | No | No editable por el médico desde Salud 365. |
-
El TITULAR y ADMINISTRADOR modifican los campos administrativos editables. Por ejemplo: nombres y apellidos; documento de identidad (tipo y número); fecha de nacimiento; género (Femenino, Masculino, Otros); dirección (opcional); celular según formato y país (máximo dos números). Forma de pago. El correo no se modifica desde el perfil.
-
El MEDICO modifica campos editables. Por ejemplo:
| Campo | ¿Editable? | Recomendación funcional |
|---|---|---|
| Género | Sí | Permitir actualizar según catálogo definido. |
| Fotografía de perfil | Sí | Permitir cargar, reemplazar o eliminar. |
| Celular principal | Sí | Validar código de país y formato. |
| Celular secundario | Sí | Opcional; máximo dos números en total. |
| Dirección | Sí | Opcional, si se requiere administrativamente. |
| País de residencia | Sí, condicionado | Si no afecta la habilitación profesional. |
| Descripción profesional | Sí, condicionado | Editable si EGD permite actualizarla y se define su validación. |
| Idiomas de atención | Sí, condicionado | Si EGD admite actualizar esta información. |
- Se validan los cambios y se registra la actualización. Para la foto del TITULAR y de cada PACIENTE autorizado, se permite cargar, encuadrar, reemplazar o quitar la imagen. Si el titular tiene su propia ficha de paciente, su fotografía se actualiza también en esa ficha; no se modifican las fotos de otros pacientes. Cambiar contraseña utiliza la recuperación por dígitos enviados al correo, también para el MÉDICO.
Validaciones: cambios de identidad requieren control reforzado.
Integración / datos: Salud 365 y EGD; catálogo de campos como tipo de documento de identidad y genero, etc.
Criterios de aceptación: el usuario ve datos actualizados y solo puede cambiar campos permitidos; puede gestionar la foto del titular y de cada paciente autorizado; la foto del titular se refleja en su propia ficha de paciente cuando exista; la recuperación de contraseña sigue el mismo mecanismo de correo para los perfiles de cuenta.
Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.
RF-01-006 · Creación y validación interna de usuario médico
Sección titulada «RF-01-006 · Creación y validación interna de usuario médico»Objetivo: Dar de alta a profesionales médicos autorizados sin permitir autorregistro público como médico.
Actores: Administrador autorizado, Salud 365
Precondiciones: Administrador autenticado con permiso de gestión de médicos; datos profesionales disponibles.
Flujo principal (propuesto):
-
El administrador accede a Gestión de médicos y selecciona Medico donde se le generara un Usuario.
-
Ingresa identidad, datos de contacto, colegiatura, especialidad y demás campos que apruebe Salud 365conforme a los datos y condiciones de EGD. Posibles valores :Nombres y Apellidos;Documento de identidad(Tipo y Número); fecha nacimiento; genero( Femenino, Masculino, Otros);dirección(opcional);Correo válido y normalizado; celular según formato y país(maximo dos números); contraseña conforme a política de seguridad.
-
El sistema valida campos, duplicidad y formato; el administrador verifica la habilitación profesional mediante el procedimiento definido.
-
El administrador confirma el alta; Salud 365 crea o vincula la cuenta y asigna el rol MEDICO únicamente tras validación.
-
Se registra guardando identificadores y estado.
-
Se envía invitación de activación al médico.
Alternativas / excepciones: Profesional duplicado, habilitación no comprobada, correo ya asociado a TITULAR.
Validaciones: Solo administradores autorizados; no autoasignación; verificación profesional documentada.
Criterios de aceptación: Ningún usuario público puede convertirse en médico por sí mismo; solo cuentas aprobadas acceden al acto médico de Salud 365; la operación es trazable.
Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.
RF-01-007 · Creación y gestión interna de usuario administrador
Sección titulada «RF-01-007 · Creación y gestión interna de usuario administrador»Objetivo: Permitir que un administrador autorizado cree y gestione cuentas administrativas sin exponer este rol al autorregistro.
Actores: Administrador autorizado y Salud 365.
Precondiciones: Cuenta administradora habilitada con permiso de gestión de administradores.
Flujo principal (propuesto):
-
El administrador autorizado accede a Gestión de usuarios internos.
-
Registra datos de identidad y contacto del nuevo administrador(Nombres y Apellidos;Documento de identidad(Tipo y Número); fecha nacimiento; genero( Femenino, Masculino, Otros);dirección(opcional);Correo válido y normalizado; celular según formato y país(maximo dos números); contraseña conforme a política de seguridad)
-
El sistema valida duplicidad, campos y autorización del creador.
-
Se asigna el rol ADMINISTRADOR con permisos definidos y se registra quién autorizó el alta.
-
El nuevo administrador accede solo a los módulos administrativos y reportes permitidos.
Alternativas / excepciones: Intento de asignación sin privilegio, cuenta duplicada.
Validaciones: Prohibir autorregistro administrativo; autorización de alto privilegio; trazabilidad; mínimo privilegio.
Integración / datos: Cuenta, rol, permisos, historial de cambios.
Criterios de aceptación: Solo personal habilitado crea administradores; el administrador no obtiene acceso clínico irrestricto por su rol; altas y cambios quedan auditados.
Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.
Matriz inicial de permisos por perfil
Sección titulada «Matriz inicial de permisos por perfil»Nota: una cuenta tiene un único rol. Los permisos se aplican según el perfil y la autorización de cada operación.
El usuario pagador y el paciente son entidades conceptualmente distintas; un mismo usuario puede cumplir ambos roles.
Los registros de usuarios deben existir en Salud 365.
Los registros de pacientes deben existir en Salud 365 y EGD(proceso asincrono); no se asume equivalencia de esquemas ni credenciales.
Los registros de médicos deben existir en Salud 365 y EGD; no se asume equivalencia de esquemas ni credenciales. El Salud 365 debe existir una configuración donde se indique el uso y lógica de médicos, especiales y disponibilidad, del mismo Salud 365 o de EGD. En esta fase, EGD rige los datos profesionales, las especialidades y la disponibilidad médica.
Toda autorización debe validarse en backend; las pantallas no son una barrera suficiente.
Se propone auditar altas, accesos, cambios de perfil y fallos de integración, con controles de privacidad y retención por definir.
No se considerarán confirmadas APIs de EGD hasta contar con contratos y pruebas del proveedor.
7.1. Decisiones funcionales confirmadas en esta revisión
Sección titulada «7.1. Decisiones funcionales confirmadas en esta revisión»Se conservan los campos del registro descritos en este módulo; correo y celular son datos previstos y la contraseña se utiliza para autenticación. La cuenta permanece pendiente hasta verificar el correo y se activa después de esa verificación.
El acceso se realiza con correo electrónico y contraseña, no con OTP o enlace mágico como mecanismo principal.