Cada clínica dental está aislada
Una clínica dental (tenant) es la cuenta del cliente. Cada registro operativo (sedes, bodegas, catálogo, existencias, pedidos, aprobaciones, custodia) pertenece a una sola clínica dental.
- La clínica sale de tu sesión, nunca de lo que envía el navegador. En cada solicitud, muveya comprueba que tengas una membresía activa en la clínica de tu sesión, y solo entonces lee o escribe los registros de esa clínica.
- La capa de datos exige una clínica. Toda consulta de registros de clínica lleva la clínica automáticamente; una consulta sin ella falla en lugar de leer todo, y una consulta que nombra otra clínica se rechaza.
- Un registro de otra clínica parece no existir. Pedir un id que pertenece a otra clínica dental responde “no encontrado”, nunca “prohibido”, para que nadie pueda saber que existe.
- El acceso de una persona termina en un momento exacto. Cuando se suspende o retira a alguien, muveya marca una hora de corte: las sesiones, claves de API y vínculos de WhatsApp emitidos antes de ella dejan de funcionar.
- Las claves de API pertenecen a una clínica. La API pública obtiene la clínica de la clave y nunca acepta un selector de clínica.
Autenticación
- Proveedor de identidad. Las contraseñas y el acceso con Google los verifica Stytch, el proveedor de identidad de muveya. muveya nunca guarda tu contraseña: el registro de la cuenta no tiene un campo de contraseña.
- Sesión propia de muveya. Después de que el proveedor te verifica, muveya emite su propia sesión. El navegador recibe un token aleatorio en una cookie
__Host-conHttpOnly,SecureySameSite=Strict; la base de datos guarda solo un hash de él. - Protección contra solicitudes entre sitios. Los cambios exigen la cookie estricta, un origen del mismo sitio y un segundo token que se deriva de la sesión y nunca se guarda.
- Duración de la sesión. Una sesión termina tras 30 minutos sin actividad y, como máximo, 30 días después de iniciarla. Cerrar sesión la termina en el servidor.
- Intentos de acceso. Después de 10 intentos fallidos con el mismo correo desde la misma red en 15 minutos, esa combinación queda bloqueada 15 minutos. El contador guarda un hash, no el correo ni la dirección.
- Sin enumeración de cuentas. Una contraseña incorrecta, un correo desconocido, una cuenta sin verificar y un código de verificación faltante reciben la misma respuesta, y pedir un enlace de verificación siempre muestra la misma confirmación.
- Enlaces por correo. Los enlaces de verificación y de invitación llevan su secreto después del
#de la dirección, que los navegadores nunca envían a un servidor, y la consola lo quita de la barra de direcciones apenas se abre la página. Los enlaces son de un solo uso: los de verificación y contraseña duran 24 horas, los de invitación 24 horas, y la verificación de correo propia de la invitación 10 minutos. - Invitaciones. Al abrir una invitación se muestra la dirección de la persona invitada enmascarada (por ejemplo
a***@clinicanorte.com), y nada se acepta hasta que la persona revisa el acceso y selecciona Aceptar invitación.
Segundo factor (MFA)
- Puedes agregar una aplicación de autenticación (TOTP) desde Seguridad de la cuenta. Es opcional.
- Una vez agregada, cada inicio de sesión en tu cuenta, con contraseña o con Google, exige el código de seis dígitos.
- Las acciones sensibles (cambios del equipo, aprobaciones, correcciones de existencias, importaciones y exportaciones del catálogo) están marcadas para un segundo factor, pero hoy muveya no lo pide antes de ellas.
- Las claves de API nunca llevan un segundo factor.
Mínimo privilegio y alcance de sedes
- Los roles incluyen muy poco. Ningún rol incluye permisos de inventario, pedidos, aprobaciones, entregas, reportes, costos, valores de pedidos ni referencias de pacientes: cada uno se debe otorgar a la persona.
- Los permisos se revisan en el servidor en cada solicitud, junto con las sedes y bodegas de la persona. Un cambio de permisos aplica desde la siguiente acción de la persona.
- Límites en las pantallas de equipo. Una invitación solo puede ofrecer permisos y lugares que tiene quien la envía; nadie cambia su propio acceso a sedes; solo los propietarios cambian roles, invitan administradores y suspenden, retiran o cambian el acceso a sedes de un propietario; una clínica siempre conserva un propietario activo. Cualquiera que tenga
members.managepuede cambiar los permisos de cualquier miembro, incluidos los suyos, así que otórgalo solo a personas a las que confiarías todos los permisos. - Separación de funciones. Nadie aprueba su propio pedido, y una persona cuyas sedes cubren tanto el lado que abastece como el que recibe un pedido no puede además confirmar su recepción (salvo que tenga acceso a todas las sedes).
Información oculta sin permiso
muveya omite estos valores en el servidor, así que nunca llegan a una persona, una clave de API o un cliente MCP sin el permiso correspondiente:
Una excepción: quien gestiona la política de aprobación (
approvals.policy.manage) sigue recibiendo del servidor sus límites de valor sin orders.value.read; la consola solo los oculta de la vista.
El historial de custodia, las listas de preparación, las alertas de existencias, los reportes y exportaciones de analítica y los mensajes de WhatsApp nunca los incluyen para nadie. Las claves de API nunca pueden leer valores de pedidos ni referencias de pacientes. Los registros de la aplicación ocultan credenciales, cookies, cuerpos de solicitudes, costos, totales, justificaciones y referencias de pacientes y de atención.
Referencias de pacientes
muveya no es una ficha clínica. Un pedido clínico puede llevar una referencia del paciente (patientRef), y una salida de existencias puede llevar una referencia de atención: ambas son códigos opacos que tomas de tu propio sistema clínico o de gestión, por ejemplo ext-7f3a.
- Cifradas en reposo. Cada referencia se cifra campo por campo con AES-256-GCM antes de guardarse. No existe una copia buscable.
- Visibles solo con permiso. Se descifran solo para quienes tienen
orders.patient_ref.read. Crear un pedido clínico requiereorders.clinical.create. - Nunca se exportan. Quedan fuera de la API pública, de MCP, de las exportaciones de analítica y de los registros de la aplicación.
- Límites. Una referencia del paciente tiene hasta 200 caracteres. Una referencia de atención tiene hasta 64 caracteres: letras, dígitos y
._:/-, empieza con una letra o un dígito y no lleva espacios.
Un historial confiable
- Al registro de movimientos solo se agregan filas. Cada recepción, consumo, traslado, reserva, preparación, despacho, devolución, cuarentena, vencimiento y baja es un movimiento nuevo; nada se edita ni se borra. Una corrección es un movimiento compensatorio nuevo (
adjust_gainoadjust_loss), nunca un cambio en el pasado. - Los pasos de custodia son eventos separados. Aprobación, preparación, despacho, entrega, recepción y cierre quedan registrados cada uno con quién lo hizo y cuándo.
- Registro de auditoría. muveya guarda registros de auditoría, entre otros, de: cambios del equipo (invitaciones creadas, reenviadas, aceptadas y revocadas; personas suspendidas, retiradas y reactivadas), decisiones de aprobación y aprobaciones automáticas, correcciones de existencias con sus solicitudes y decisiones, conciliaciones de conteos, cuarentenas de lotes y cambios de mínimos, importaciones y exportaciones del catálogo (incluidos los intentos rechazados), pasos de custodia, confirmaciones por WhatsApp, creación y revocación de claves de API, y cada llamada a herramientas y lectura de recursos de MCP. El contenido de un registro no se puede cambiar y los registros nunca se borran. La hora la fija el reloj del servidor.
Todavía no hay una pantalla ni una API para leer el registro de auditoría en producción, y el permiso
audit.read no habilita nada hoy. Si necesitas información de ese registro, escribe a team@muveya.com.Claves de API y MCP
- Formato. Las claves se ven como
mvy_test_EXAMPLE..., con una suma de verificación al final. muveya muestra una clave una sola vez y guarda solo su hash: no se puede recuperar. - Una clínica, scopes de lectura. Una clave pertenece a una clínica dental y lleva uno o más de siete scopes de lectura; una clave sin scopes se rechaza. No hay scopes de escritura. La única solicitud que crea algo es
POST /v1/analytics/exports, que inicia una exportación de analítica. - Límites. Hasta 10 claves activas por clínica dental, y 120 solicitudes por minuto por clave en
/v1; MCP usa OAuth por separado. - Vigencia. Una clave no tiene fecha de vencimiento; funciona hasta que se revoca, y la revocación es inmediata. Una clave deja de funcionar cuando se suspende o retira a quien la creó, y reactivar a esa persona no la recupera.
- Errores. Las fallas se devuelven como documentos de problema (problem details) según RFC 9457, y una clave inválida, revocada o desconocida siempre recibe la misma respuesta.
- MCP. El endpoint
/mcpusa una conexión OAuth personal, limitada por los permisos y sedes actuales del miembro. Cada llamada a herramientas queda auditada sin su contenido.
La consola todavía no tiene una pantalla para crear o revocar claves de API. Para obtener o revocar una clave, escribe a team@muveya.com. Consulta Autenticación y Conectar un cliente.
- Una persona vincula su número de WhatsApp con su propia membresía mediante un código de un solo uso que dura 10 minutos; muveya guarda solo un hash del código. Un número se vincula con una sola membresía a la vez.
- muveya guarda el número de WhatsApp vinculado para enrutar los mensajes.
- Los mensajes llevan códigos de caja, nombres de insumos y bodegas y cantidades, nunca costos, valores de pedidos ni referencias de pacientes.
- Nada cambia las existencias hasta que la persona toca una confirmación explícita, y cada paso revisa los mismos permisos y bodegas que la consola.
- Los menús y botones son fijos. No hay IA en la conversación.
- El vínculo de una persona suspendida o retirada deja de funcionar.
Inteligencia artificial
muveya no tiene funciones de IA en producción. No envía tus datos ni los datos de tu cuenta a proveedores de modelos de IA. El resumen gerencial disponible por MCP es un cálculo fijo sobre tus métricas, no un texto generado. Antes de activar cualquier función de IA, Woku se compromete a actualizar la Política de privacidad y la lista de subencargados.Dónde viven tus datos
- Aplicación, archivos y caché: Amazon Web Services, región
us-east-1(Estados Unidos). Los archivos guardados son privados, cifrados y se entregan solo por TLS, mediante enlaces que vencen en menos de una hora. - Base de datos: MongoDB Atlas.
- Correo: se envía desde
no-reply@muveya.coma través de Amazon SES. - En tránsito: todos los hosts públicos (
console.muveya.com,api.muveya.com,muveya.com) funcionan con HTTPS; el HTTP simple se redirige.
Documentos legales
Cada documento se publica en inglés, español y portugués (cambia
es por en o pt en la dirección). La versión vigente es la 1.0, desde el 15 de septiembre de 2026. La consola enlaza los Términos de servicio y la Política de privacidad desde sus pantallas de inicio de sesión y registro.
Para ejercer un derecho sobre tu cuenta personal, incluida su eliminación, sigue la sección 12 de la Política de privacidad. Si tu solicitud se refiere a registros dentro de una clínica dental, contacta primero a esa clínica.
Reporta un problema de seguridad
Si encuentras una vulnerabilidad o sospechas un incidente, escribe a diego@muveya.com, la dirección de privacidad y seguridad que indican la Política de privacidad, los Términos de servicio y el Acuerdo de tratamiento de datos.- Describe qué encontraste, dónde y cómo reproducirlo.
- No incluyas datos personales innecesarios en el primer mensaje, y nunca incluyas contraseñas, claves de API ni información de pacientes.
- No accedas, cambies ni borres datos de clínicas dentales distintas de la tuya.
Páginas relacionadas
Roles y permisos
Permisos, alcance de sedes y omisión de datos.
Seguridad de la cuenta
Agrega un segundo factor a tu cuenta.
Equipo
Suspende o retira accesos.
Autenticación
Cómo funcionan las claves de API.