Documentación Técnica de OpenS

Análisis formal sobre los patrones arquitectónicos, las políticas de seguridad y el aislamiento de datos multiinquilino (multitenancy) implementados en el CRM Clínico.

01. Arquitectura SPA Híbrida (Astro + Svelte)

OpenS utiliza un enfoque híbrido de alto rendimiento. Astro actúa como un enrutador del lado del servidor (SSR) y un guardián de rutas. La validación inicial del estado de la sesión se gestiona a nivel de middleware interceptando las cookies del navegador (concretamente sb-access-token).

Una vez aprobada la autenticación en Astro, se inicializa el componente principal de Svelte (MainApp.svelte). A partir de este momento, la aplicación se comporta como una Aplicación de Página Única (SPA). Esto permite realizar transiciones fluidas, búsqueda rápida de expedientes en memoria local y actualizaciones instantáneas sin recargar la página.

Diagrama de Enrutamiento y Datos

graph TD
    Client[Cliente / Navegador] -->|Petición HTTP /app| Router[Astro Router]
    Router -->|Lectura Cookie: sb-access-token| Guard{Verifica Token}
    Guard -->|No Válido| Redirect[Redirección /login]
    Guard -->|Válido| SvelteApp[Carga MainApp Svelte]
    SvelteApp -->|Conexión Directa Client-side| Supabase[(Supabase Backend)]
    Supabase -->|Sincronización de Sesión / RLS| Client

02. Autenticación "Invite-Only" (Zero Passwords)

Con el propósito de mitigar vulnerabilidades relacionadas con credenciales débiles y phishing, OpenS descarta el registro público. La base de usuarios se maneja bajo un estricto modelo de Club Privado.

El flujo de autenticación confía plenamente en el proveedor OAuth de Google. Los pasos del inicio de sesión son:

  • El profesional inicia la solicitud de autenticación mediante el botón de Google.
  • Supabase Auth redirecciona el flujo a la verificación federada de Google.
  • Al retornar el token de identidad (JWT), un trigger de base de datos valida si el correo electrónico del profesional reside en la tabla de cuentas pre-autorizadas.
  • Si el correo electrónico no está pre-autorizado, la sesión se destruye automáticamente en el backend y se deniega el acceso.

03. Base de Datos y Aislamiento (Multitenancy)

El motor de persistencia es PostgreSQL provisto por Supabase. Todos los esquemas de datos clínicos imponen un modelo multiinquilino estricto mediante la columna profesional_id (que almacena el UUID del profesional asignado).

El aislamiento absoluto se garantiza a nivel del motor a través de políticas de **Row Level Security (RLS)**. Cualquier consulta realizada por el cliente es interceptada y filtrada automáticamente por las siguientes reglas RLS lógicas:

// Política RLS básica para lectura de Pacientes

CREATE POLICY tenant_isolation_policy   ON public.pacientes   FOR ALL   USING (profesional_id = auth.uid());

Para los documentos y archivos clínicos digitalizados (como fotos de récipes o informes médicos), OpenS utiliza Supabase Storage. Los archivos se alojan en un bucket configurado como privado. La descarga o visualización de dichos recursos requiere un enlace firmado con caducidad corta (tokenizado), el cual solo se expide si el solicitante supera la validación RLS de la base de datos.

Diagrama de Aislamiento de Datos

graph TD
    Req[Petición: Buscar Pacientes] -->|Envía JWT del Profesional| DB[(PostgreSQL Engine)]
    DB -->|Filtro Automático JWT| RLS[Verifica: profesional_id == auth.uid]
    RLS -->|Filtro Exitoso| Select[Retorna solo filas del Tenant]
    Select -->|Respuesta Segura| Res[Svelte App / Frontend]
    RLS -->|Intento de evasión / bypass| Denied[Resultado Vacío o 403 Denegado]