Seguridad y protección de datos

• La clínica (el Suscriptor) es el responsable del tratamiento: recaba el consentimiento del paciente, decide qué se registra y atiende los derechos ARCO de sus pacientes.
• Optisave es el encargado del tratamiento: almacena y procesa esos datos únicamente para prestar el servicio contratado, conforme a la LFPDPPP.

Antes de operar, el usuario acepta los Términos, el Aviso de Privacidad y un reconocimiento de esa responsabilidad. Al dar de alta un paciente, la clínica declara haber obtenido el consentimiento expreso (fecha, versión del texto y usuario que confirma).

Optisave no usa una base de datos física distinta por clínica. Toda la información vive en una misma infraestructura PostgreSQL (Supabase), y el aislamiento se aplica en cada fila:

• Pacientes, citas, consultas, clínicas y módulos quedan ligados a una cuenta (account_id).
• Las políticas de seguridad a nivel de fila (RLS) impiden que un usuario autenticado lea o escriba datos de otra clínica, salvo que sea miembro de esa cuenta con un rol válido.
• El rol anónimo no tiene privilegios sobre las tablas clínicas. El acceso público (QR, auto-registro, reservas) no consulta tablas completas: pasa por funciones acotadas, con token de caducidad, que solo devuelven los campos necesarios (nombre del negocio, horarios, disponibilidad).

En la práctica: la clínica A no puede ver pacientes, citas ni expedientes de la clínica B. Un doctor solo ve lo que su membresía y sus permisos le autorizan.

• Inicio de sesión: correo y contraseña (el hash de la contraseña lo guarda el proveedor de autenticación; nunca en claro) o acceso federado con Google (OAuth 2.0).
• Verificación de correo en el alta por email.
• Autenticación multifactor (MFA) disponible para todos los usuarios. Si la cuenta la tiene activada, el acceso a /home exige el segundo factor. Para administradores de la plataforma (super admin) el MFA es obligatorio.
• Roles y permisos (RBAC): owner, miembros y jerarquía de roles. Las acciones sensibles (invitar, cambiar ajustes, gestionar facturación) requieren el permiso correspondiente.
• Las rutas de la aplicación y las APIs internas vuelven a comprobar la sesión y la pertenencia a la cuenta antes de devolver datos.
• Protección CSRF en peticiones que modifican datos, y Content Security Policy (CSP) en producción, incluyendo Trusted Types (require-trusted-types-for 'script') para bloquear HTML y scripts no confiables.

• En tránsito: TLS 1.2 o superior (HTTPS) entre el navegador y la plataforma.
• En reposo: cifrado de discos en la infraestructura de Supabase. No hay un cifrado adicional campo a campo del expediente en la aplicación.
• Respaldos periódicos como medida de continuidad ante fallas técnicas. No se compromete un RPO/RTO específico.

El expediente electrónico incorpora campos y controles alineados con la NOM-024-SSA3 (fase aditiva):

• Diagnóstico CIE-10 consultable.
• Número de expediente clínico.
• Firma del médico al cerrar la consulta.
• Huella de integridad del contenido clínico (hash_contenido), calculada al guardar a partir del JSON del expediente (custom_fields), para detectar alteraciones posteriores del registro.
• Bitácora audit_expediente: creación, edición y firma, con usuario, fecha y detalle de cambios relevantes. Cada usuario solo registra y consulta su propia traza de auditoría.

Es importante entender el alcance de estos controles: no impiden por sí solos que alguien modifique un expediente; sirven para trazabilidad y detección de inconsistencias.

Cuando el expediente se edita por la aplicación (flujo normal)

• Al crear o actualizar una consulta desde Optisave, la plataforma recalcula hash_contenido junto con el guardado del contenido clínico.
• Un trigger en base de datos registra en audit_expediente la acción (creación, edición o firma), el usuario autenticado y si cambió el contenido relevante.

Lo que el hash sí ayuda a detectar

• Si alguien altera custom_fields directamente en la base de datos sin actualizar hash_contenido, la huella guardada ya no coincidirá con el contenido actual (tampering detectable mediante verificación).
• Las ediciones hechas por usuarios autorizados vía la app dejan huella coherente y evento en la bitácora.

Lo que no garantiza (límites técnicos)

• No hay un candado criptográfico en la base de datos que bloquee un UPDATE si el hash no cuadra. Postgres no recalcula ni valida la huella automáticamente en cada cambio de fila.
• Quien tenga acceso administrativo a la infraestructura (por ejemplo, credenciales de administrador del proyecto en Supabase, rol service_role o acceso SQL directo) puede, en principio, modificar consultas, huellas y registros de auditoría. Es el mismo límite de cualquier SaaS clínico sin almacenamiento WORM externo.
• Un atacante con ese nivel de acceso podría, además, actualizar contenido y huella a la vez, si replica el algoritmo de cálculo. Por eso la bitácora complementa, pero no sustituye, controles organizacionales y de acceso privilegiado.
• La bitácora está pensada para registrar eventos, no para ser inmutable frente a un superusuario de la base de datos.

En la práctica: el hash y audit_expediente protegen contra uso indebido por personal clínico dentro de la app, errores y alteraciones detectables; no sustituyen la gobernanza de accesos de la clínica (MFA, bajas inmediatas, roles mínimos) ni auditorías externas si se sospecha acceso al panel de infraestructura.

Si se pierde internet durante una consulta, Optisave puede guardar temporalmente pacientes, citas e inventario en el navegador del dispositivo (almacenamiento local) y sincronizar al recuperar la red.

Eso implica que hay datos clínicos en ese equipo mientras el modo offline esté activo. Use equipos de la clínica, cierre sesión al terminar y evite computadoras compartidas o de acceso público.

El QR de sala de espera permite que el paciente capture sus datos (incluidos antecedentes de salud) sin cuenta. El acceso se valida con un token de un solo uso temporal que caduca. Quien tenga el token vigente puede registrar o buscar un folio de esa clínica, no de otras.

No imprima ni publique un QR vencido o de un entorno de pruebas. Renueve el token si deja de usarse el cartel o cambia de sucursal.

El agente de WhatsApp es un canal opcional. Los mensajes transitan por la infraestructura de Meta. No envíe por ese canal información clínica innecesaria; úselo para agenda y recordatorios operativos. Los webhooks de WhatsApp se validan con firma HMAC SHA-256.

Si ocurre un incidente que afecte datos personales —incluido uno imputable a un subencargado—, Optisave notificará al Suscriptor sin dilación indebida y, cuando sea razonablemente posible, dentro de 72 horas de tener conocimiento, por correo y, en su caso, aviso en la plataforma. La notificación describirá la naturaleza del incidente, las categorías afectadas y las medidas adoptadas o recomendadas, sin perjuicio de las obligaciones ante el INAI y los titulares.

Los titulares pueden ejercer Acceso, Rectificación, Cancelación y Oposición, además de portabilidad y limitación de tratamiento. El procedimiento está en el Aviso de Privacidad.

Como la clínica es la responsable, las solicitudes de pacientes sobre su expediente deben atenderse primero en la clínica. Optisave colabora como encargado cuando la clínica lo requiera.

• Aviso en consola: al abrir las herramientas de desarrollo aparece un aviso grande (rojo) advirtiendo que pegar código es una estafa (self-XSS) y que puede conllevar el baneo permanente de la cuenta.
• Trusted Types: el navegador exige que el HTML y los scripts asignados al DOM pasen por una política. Se eliminan etiquetas script/iframe y atributos on*. En producción se rechaza eval / new Function (salvo JSON-LD). Las URLs de script solo pueden ser del mismo origen.
• Opción de baneo: las violaciones de Trusted Types o de CSP de scripts se registran para revisión. Un Super Admin puede banear la cuenta desde el panel de administración (la sesión deja de ser válida). No hay baneo automático: un médico no es expulsado por abrir DevTools ni por un error inocuo.