MedTime Technical Specification - Executive Summary¶

Identificador: TECH-SUMMARY-001 Version: 1.0.0 Fecha: 2025-12-08 Autor: SpecQueen Technical Division

1. Resumen Ejecutivo¶

1.1. Proposito¶

MedTime es una aplicacion movil de gestion de medicamentos que prioriza la privacidad del pacientemediante una arquitecturaZero-Knowledge. El servidor nunca tiene acceso a datos de salud en texto claro.

1.2. Arquitectura Dual 95/5¶

flowchart LR
    subgraph CLIENT["CLIENTE (95%)"]
        C1["Logica negocio"]
        C2["Cifrado E2E"]
        C3["Base datos local"]
        C4["UI/UX"]
        C5["Alertas"]
    end

    subgraph SERVER["SERVIDOR (5%)"]
        S1["Auth tokens"]
        S2["Sync blobs"]
        S3["Push routing"]
        S4["Audit logs"]
        S5["Rate limiting"]
    end

    CLIENT <-->|"Encrypted Blobs"| SERVER

    style CLIENT fill:#e3f2fd,stroke:#1565c0
    style SERVER fill:#fce4ec,stroke:#c62828

1.3. Zero-Knowledge by Design¶

Datos en transito: TLS 1.3 + blobs cifrados AES-256-GCM
Datos en servidor: Solo blobs opacos (el servidor no puede descifrar)
Datos en cliente: Cifrado local con claves derivadas de usuario
Compliance: HIPAA, FDA 21 CFR Part 11, LGPD

2. Estadisticas de la Especificacion¶

2.1. Totales¶

Metrica	Valor
Documentos totales	43
Lineas de especificacion	~60,000+
APIs OpenAPI	14
Modelos de datos	12
ADRs	5
Iteraciones completadas	15

2.2. Por Categoria¶

Categoria	Docs	Lineas
Documentos principales	8	~11,000
APIs OpenAPI	14 + schemas	~15,600
Modelos de base de datos	12	~16,700
Arquitectura mobile	2	~12,400
Performance	2	~3,000
Knowledge base (ADRs)	5	~1,500

3. Principios Arquitectonicos¶

3.1. Clean Architecture¶

flowchart TB
    subgraph PRESENTATION["PRESENTATION"]
        P1["SwiftUI (iOS) / Jetpack Compose (Android)"]
    end

    subgraph DOMAIN["DOMAIN"]
        D1["Use Cases, Entities, Repository Interfaces"]
    end

    subgraph DATA["DATA"]
        DA1["Repositories, Data Sources, Mappers"]
    end

    PRESENTATION --> DOMAIN
    DATA --> DOMAIN

    style PRESENTATION fill:#fff3e0,stroke:#e65100
    style DOMAIN fill:#e8f5e9,stroke:#2e7d32
    style DATA fill:#e3f2fd,stroke:#1565c0

Independencia de frameworks: El dominio no depende de UI o persistencia
Testeable: Cada capa es testeable en aislamiento
Mantenible: Cambios en una capa no afectan otras

3.2. Offline-First¶

Todas las operaciones funcionan offline
Sync cuando hay conexion disponible
Conflictos resueltos con Last-Write-Wins + merge
Queue de operaciones pendientes

3.3. Security-First¶

Cifrado E2E obligatorio para datos de salud
Claves nunca salen del dispositivo
Biometria para acceso rapido
Session tokens con rotacion automatica

4. Stack Tecnologico¶

4.1. iOS¶

Componente	Tecnologia
UI	SwiftUI
Arquitectura	Clean Architecture + MVVM
Persistencia	SwiftData
Networking	URLSession + async/await
Cifrado	CryptoKit (AES-256-GCM)
Key storage	Keychain + Secure Enclave
Push	APNs
Widgets	WidgetKit
Watch	WatchKit + WatchConnectivity

4.2. Android¶

Componente	Tecnologia
UI	Jetpack Compose
Arquitectura	Clean Architecture + MVVM
DI	Hilt/Dagger
Persistencia	Room + SQLCipher
Networking	Retrofit + OkHttp + Coroutines
Cifrado	javax.crypto (AES-256-GCM) + argon2kt
Key storage	Android Keystore
Push	FCM
Widgets	Glance
Watch	Wear OS Data Layer API

4.3. Servidor¶

Componente	Tecnologia
Base de datos	Supabase (PostgreSQL)
Autenticacion	Firebase Auth
Storage	Supabase Storage (blobs)
Functions	Supabase Edge Functions
Push	Firebase Cloud Messaging

4.4. Infraestructura¶

Componente	Tecnologia
CI/CD	GitHub Actions
Mobile deploy	Fastlane
Monitoring	Sentry (client), Supabase (server)
Secrets	GitHub Secrets, env files

5. Metricas de Performance (SLAs)¶

5.1. Cliente¶

Metrica	Target
Cold start	< 2s
Warm start	< 500ms
Frame rate	60 FPS
Memory (normal)	< 150 MB
Battery (daily)	< 2%
Storage (base)	< 50 MB

5.2. Servidor¶

Metrica	Target
Auth latency (P95)	< 500ms
Sync latency (P95)	< 1s
Error rate	< 0.1%
Availability	99.9%

5.3. Cifrado¶

Operacion	Target
AES-256-GCM encrypt	< 5ms/KB
AES-256-GCM decrypt	< 5ms/KB
Argon2id key derivation	< 500ms
Keystore access	< 50ms

6. APIs Principales¶

6.1. Categorias¶

Categoria	APIs	Endpoints
Autenticacion	API-AUTH-001	8
Core	API-MED, API-USR	12
Sync	API-SYNC-001	6
Alertas	API-ALT, API-NTF	10
Calendario	API-CAL, API-ADH	14
Analisis	API-ANA, API-RX	12
Interacciones	API-INT-001, API-INT-002	8
Catalogos	API-CAT, API-EST	6

6.2. Principios de API¶

OpenAPI 3.0: Todas las APIs documentadas
Versionado URI: /api/v1/resource
Autenticacion: Bearer tokens (Firebase)
Rate limiting: Por tier (Free/Pro/Perfect)
Paginacion: Cursor-based para listas

7. Modelos de Datos¶

7.1. Por Dominio¶

Dominio	Modelo	Entidades principales
Auth	MDL-AUTH-001	users, sessions, devices
Medicamentos	MDL-MED-001	medications, schedules, doses
Usuarios	MDL-USR-001	profiles, preferences
Alertas	MDL-ALT-001	push_tokens, notification_queue
Notificaciones	MDL-NTF-001	patterns, suggestions
Calendario	MDL-CAL-001	habits, moments, events
Adherencia	MDL-ADH-001	daily, streaks, insights
Analisis	MDL-ANA-001	analyses, results
Recetas	MDL-RX-001	prescriptions, OCR
Interacciones	MDL-INT-001/002	med-med, med-study

7.2. Clasificacion de Datos¶

Tipo	Almacenamiento	Ejemplo
LOCAL_ONLY	Solo dispositivo	Medicamentos, dosis
SYNC_ENCRYPTED	Servidor como blob	Historial, preferencias
SERVER_SOURCE	Solo servidor	Catalogos >100 registros
EPHEMERAL	En memoria	Tokens de sesion

8. Arquitectura de Seguridad¶

8.1. Cliente (04-seguridad-cliente.md)¶

Cifrado E2E: AES-256-GCM con claves derivadas
Key derivation: Argon2id (m=64MB, t=3, p=4)
Key storage: Keychain (iOS) / Android Keystore
Biometria: Face ID / Touch ID / Fingerprint
Secure Enclave: Para operaciones criptograficas

8.2. Servidor (05-seguridad-servidor.md)¶

RLS: Row Level Security en PostgreSQL
Audit logging: Todas las operaciones
Rate limiting: Por usuario y endpoint
OWASP Top 10: Mitigaciones documentadas

9. Testing Strategy¶

9.1. Cobertura Minima¶

Tipo	Cobertura
Unit tests	80%
Integration tests	60%
E2E tests	Flujos criticos

9.2. Tests Especiales¶

Zero-Knowledge tests: Verificar que servidor no ve datos
Offline tests: Operaciones sin conexion
Security tests: Penetration testing, OWASP

10. Compliance¶

10.1. HIPAA¶

PHI cifrado en transito y reposo
Audit trails completos
Access controls documentados
Breach notification procedures

10.2. FDA 21 CFR Part 11¶

Electronic signatures
Audit trails
System validation
Data integrity

10.3. LGPD (Mexico)¶

Consentimiento explicito
Derecho al olvido
Portabilidad de datos
Notificacion de brechas

11. Roadmap Tecnico¶

Version	Contenido	Estado
v1.0.0	Especificacion completa	Actual
v1.1.0	Postman collections	Planificado
v1.2.0	Swagger UI deployment	Planificado
v1.3.0	SDK generation	Futuro

12. Referencias Cruzadas¶

12.1. Triada de Especificacion¶

Spec	Proposito	Docs
functional-spec	QUE hacer	28 modulos
UiSpec	COMO se ve	207 pantallas
technical-spec	COMO se implementa	43 docs

12.2. Drones Tecnicos¶

Drone	Responsabilidad
ArchitectureDrone	Clean Architecture, SOLID
ApiContractDrone	OpenAPI, contratos
SecurityDrone	OWASP, cifrado
DatabaseDrone	Modelos, RLS
PerformanceDrone	SLAs, benchmarks
TestingDrone	Cobertura, trazabilidad
DevOpsDrone	CI/CD, infraestructura

13. Conclusion¶

La especificacion tecnica de MedTime v1.0.0 proporciona una base solida para la implementacion de una aplicacion de gestion de medicamentos que:

Prioriza la privacidad con arquitectura Zero-Knowledge
Funciona offline con sincronizacion inteligente
Es segura cumpliendo HIPAA, FDA, LGPD
Es performante con SLAs definidos
Es mantenible con Clean Architecture

La especificacion cubre todas las capas del sistema, desde la interfaz de usuario hasta la base de datos, con 43 documentos y mas de 60,000 lineas de especificacion tecnica.

Documento generado por SpecQueen Technical Division - IT-15 "La resistencia es futil cuando la arquitectura es perfecta."