Saltar a contenido

MedTime - Requisitos Regulatorios v1.0 (Mexico)

Identificador: MTS-REG-001 Version: 2.1.0 Fecha: 2025-12-05 Ultima Revision: Iteracion 13 - Correcciones OBS-024 a OBS-030 (INV-008, INV-009, INV-010, INV-011) Autor: SpecQueen (ComplianceDrone + ConsistencyDrone) Mercado: Mexico exclusivamente

1. Investigaciones Incorporadas en Esta Version

1. Introduccion

1.1. Alcance v1.0

Este documento establece los requisitos regulatorios para MedTime v1.0, que opera exclusivamente en Mexico. El cumplimiento se centra en:

Regulacion Prioridad Estado
LFPDPPP Critica Implementado
NOM-024-SSA3-2012 Alta Implementado
NOM-004-SSA3-2012 Media Implementado
COFEPRIS (Recetas) Alta Implementado

1.2. Regulaciones Diferidas

Las siguientes regulaciones NO aplican a v1.0 y estan documentadas en 12-roadmap-regulatorio.md:

  • HIPAA (EE.UU.) - Version 1.5+
  • LGPD (Brasil) - Version 2.0+
  • FDA 21 CFR Part 11 - Version 2.5+ (Portal Clinico para profesionales)
  • GDPR (Europa) - Version 3.0+

1.3. Principio Fundamental: Arquitectura Zero-Knowledge

MedTime implementa cifrado extremo-a-extremo (E2E)donde el servidorNUNCA accede a datos de salud en texto claro. Este principio simplifica significativamente el cumplimiento regulatorio.

2. LFPDPPP - Ley Federal de Proteccion de Datos Personales

2.1. Aviso de Privacidad (Art. 15-18)

ID Elemento Implementacion MedTime Estado
MX-AP-001 Identidad del responsable Datos de empresa en aviso OK
MX-AP-002 Datos personales recabados Lista detallada por categoria OK
MX-AP-003 Finalidades del tratamiento de los datos Descripcion clara y especifica OK
MX-AP-004 Transferencias de datos Solo proveedor Cloud USA (con consentimiento) OK
MX-AP-005 Mecanismos ARCO Seccion dedicada in-app OK
MX-AP-006 Mecanismo de revocacion Proceso documentado OK
MX-AP-007 Uso de cookies/tecnologias Politica de cookies OK
MX-AP-008 Cambios al aviso Notificacion push + in-app OK

2.1.1. Contenido del Aviso de Privacidad

El aviso de privacidad de MedTime sigue las mejores practicas del sector salud en Mexico, incluyendo ejemplos de aplicaciones de telemedicina y farmacias digitales que han sido auditadas por la autoridad de proteccion de datos.

2.1.2. Referencia de Mejores Practicas Sector Salud Mexico

  • Formato de tres capas (corto, simplificado, integral) conforme a Guia INAI 2016
  • Lenguaje claro y accesible para usuarios no tecnicos
  • Mencion explicita de datos sensibles de salud
  • Explicacion de arquitectura de proteccion tecnica
AVISO DE PRIVACIDAD - MedTime

IDENTIDAD DEL RESPONSABLE
[Nombre Legal], con domicilio en [Direccion], es responsable del tratamiento
de sus datos personales.

DATOS RECABADOS
- Identificacion: Nombre, email, telefono (cifrados con Blind Index para busqueda)
- Salud (DATOS SENSIBLES): Lista de medicamentos, dosis, horarios, recetas
- Uso: Patrones de uso, preferencias

IMPORTANTE - LISTA DE MEDICAMENTOS ANONIMIZADA:
Para mejorar nuestro servicio, MedTime puede procesar su lista de medicamentos
de forma COMPLETAMENTE ANONIMIZADA, sin posibilidad de vincularla a su identidad.
Este procesamiento utiliza:
- Generalizacion a categorias terapeuticas (ej: "Metformina" -> "Antidiabetico")
- Differential Privacy (ruido matematico que garantiza privacidad)
- Separacion total de identidad (el servidor no sabe de quien provienen los datos)

Usted puede desactivar esta funcion en cualquier momento desde Configuracion > Privacidad.
Ver: [INV-010: Anonimizacion de Medicamentos]

FINALIDADES
Primarias:
- Gestionar su tratamiento farmacologico personal
- Enviar alertas y recordatorios de medicamentos
- Almacenar su historial de tomas

Secundarias (requieren consentimiento explicito):
- Mejora del servicio mediante estadisticas ANONIMIZADAS agregadas
- Enriquecimiento de base de datos de medicamentos (sin identificar usuarios)

ARQUITECTURA ZERO-KNOWLEDGE
Sus datos de salud estan cifrados en su dispositivo con tecnologia de grado
militar (AES-256-GCM). MedTime NO puede acceder a esta informacion en texto
claro. Solo usted tiene la clave de descifrado.

CIFRADO DE PERFIL (INV-008):
Incluso sus datos de identificacion (nombre, email) estan protegidos mediante:
- Blind Index: Permite busqueda sin revelar el dato real
- Split-Key Architecture: Su clave se divide en partes para mayor seguridad
- Argon2id: Derivacion de clave resistente a ataques

TRANSFERENCIAS
Sus datos CIFRADOS se almacenan en servidores AWS (EE.UU.) bajo
consentimiento explicito otorgado durante el registro. AWS no puede
descifrar sus datos ya que no tiene acceso a su clave.

DERECHOS ARCO
Puede ejercer sus derechos de Acceso, Rectificacion, Cancelacion y
Oposicion a traves de la seccion "Privacidad" en la aplicacion o
enviando correo a: privacidad@medtime.com

Plazo de respuesta: 20 dias habiles maximo.

CAMBIOS AL AVISO
Le notificaremos cualquier cambio material mediante:
- Notificacion push
- Banner in-app
- Email (para cambios significativos)

Referencia: Ver INV-008: Cifrado de Perfil e Identificacion y INV-010: Anonimizacion de Medicamentos para detalles tecnicos.

2.2. Derechos ARCO (Art. 22-35)

Derecho Descripcion Plazo Implementacion Referencia
Acceso Conocer datos almacenados 20 dias habiles Seccion "Mis Datos" MTS-PRI-001-F01
Rectificacion Corregir datos inexactos 20 dias habiles Edicion de perfil MTS-PRI-001-F02
Cancelacion Eliminar datos 20 dias habiles Eliminacion de cuenta MTS-PRI-001-F03
Oposicion Oponerse a uso especifico 20 dias habiles Config preferencias MTS-PRI-001-F04

2.2.1. Flujo de Solicitud ARCO

flowchart TD
    A[Usuario solicita ARCO] --> B{Tipo de derecho}
    B -->|Acceso| C[Generar reporte datos]
    B -->|Rectificacion| D[Formulario edicion]
    B -->|Cancelacion| E[Proceso eliminacion]
    B -->|Oposicion| F[Config granular]

    C --> G[Entrega inmediata in-app]
    D --> H[Actualizacion + confirmacion]
    E --> I[Periodo gracia 7 dias]
    I --> J[Eliminacion irreversible]
    F --> K[Guardar preferencias]

    G --> L[Documentar en log]
    H --> L
    J --> L
    K --> L
    L --> M[Respuesta < 20 dias habiles]

2.2.2. Implementacion Tecnica ARCO

Derecho Endpoint Accion E2E
Acceso GET /api/v1/user/data-export Exporta datos cifrados + clave
Rectificacion PATCH /api/v1/user/profile Re-cifra datos modificados
Cancelacion DELETE /api/v1/user/account Elimina usuario + blobs cifrados
Oposicion PUT /api/v1/user/preferences Actualiza flags de tratamiento

2.3. Datos Sensibles de Salud (Art. 3-VI)

ID Requisito Implementacion Estado
MX-DS-001 Consentimiento expreso y por escrito Firma electronica en onboarding OK
MX-DS-002 Justificacion de necesidad Documentado en aviso OK
MX-DS-003 Medidas de seguridad reforzadas Cifrado E2E AES-256 OK
MX-DS-004 Separacion de datos sensibles Categoria aparte en BD OK

2.3.1. Clasificacion de Datos

Categoria Tipo Sensible Cifrado E2E Servidor Ve Ejemplo
Identificacion PII No Parcial* Blind Index Email, telefono
Perfil PII No Si No Nombre, fecha nacimiento
Salud Sensible Si Si No Medicamentos, dosis
Medico Sensible Si Si No Recetas, diagnosticos
Uso (Anonimizado) Operacional No No Solo agregado Categorias terapeuticas
Metadata Operacional No No Si Timestamps, tamanos blob

2.3.2. Notas sobre Proteccion de Datos (INV-008)

  • (*) Identificacion con Blind Index: Email y telefono se almacenan como HMAC-SHA256 (no reversible). El servidor puede buscar por hash pero no puede ver el valor original. Ver INV-008: Cifrado de Perfil e Identificacion.

  • Perfil cifrado E2E: Nombre completo, fecha de nacimiento y foto de perfil se cifran con la clave del usuario. El servidor almacena blobs opacos.

  • Split-Key Architecture: La clave maestra del usuario se divide usando Shamir's Secret Sharing (2-of-3):

  • Parte 1: Derivada del password (Argon2id)
  • Parte 2: Almacenada en Secure Enclave del dispositivo
  • Parte 3: Recovery Key (24 palabras BIP39)

2.3.3. Categoria "Uso" - SOLO DATOS ANONIMIZADOS (INV-010)

La categoria "Uso" esta estrictamente limitada a datos completamente anonimizados que no pueden vincularse a ningun usuario:

Dato en "Uso" Servidor Ve Vinculo a Usuario Tecnica de Anonimizacion
Categorias terapeuticas agregadas Conteos Ninguno Generalizacion + k-anonymity
Patrones de horarios (agregados) Distribucion Ninguno Differential Privacy LDP
Estadisticas de adherencia Promedios Ninguno Agregacion con ruido
Combinaciones comunes de meds Frecuencias Ninguno Supresion de raros (k<1000)

CRITICO: El servidor NUNCA recibe datos de "Uso" que puedan vincularse a un usuario especifico. La anonimizacion ocurreen el dispositivo antes de cualquier transmision. Ver INV-010: Anonimizacion de Medicamentos.

2.4. Consentimiento (Art. 8-10)

2.4.1. Tipos de Consentimiento Requerido

CONCLUSION INV-009: Segun la investigacion INV-009: Consentimiento para Datos de Salud y la sentencia TJUE C-21/23 (Lindenapotheke),una lista de medicamentos vinculada a una persona identificable constituye un dato de saludy requiereconsentimiento EXPLICITO.

2.4.2. Analisis de Necesidad de Consentimiento por Escenario

Escenario Datos Tratados Vinculo a Persona Consentimiento
Usuario registrado, medicamentos sincronizados Lista completa SI (email, perfil) EXPLICITO
Modo offline-only (sin cuenta) Solo en dispositivo NO (sin cuenta) TACITO
Compartir con cuidador/medico Lista + adherencia SI (identificable) EXPLICITO
Analitica anonimizada (INV-010) Estadisticas NO (disociado) NO REQUERIDO

2.4.3. Tipos de Consentimiento Implementados

Tipo Momento Forma Revocable Dato Protegido Implementacion
Tacito Registro Uso de app Si Funcionalidad basica Terminos de servicio
EXPLICITO Datos salud Firma electronica Si Lista medicamentos Pantalla dedicada + biometria
EXPLICITO Datos sensibles Firma electronica Si Recetas, diagnosticos Biometria + PIN
EXPLICITO Transferencia Checkbox explicito Si Datos cifrados a USA Onboarding
NO REQUERIDO Analytics N/A N/A Datos anonimizados INV-010 (opt-out disponible)

  1. LFPDPPP Art. 9: "Tratandose de datos personales sensibles, el responsable debera obtener el consentimientoexpreso y por escrito del titular"

  2. Sentencia TJUE C-21/23: Cualquier vinculo medicamento-persona constituye dato de salud, incluso sin receta medica

  3. Irrelevancia del Cifrado E2E: El cifrado protege los datos pero NO elimina su naturaleza sensible. El consentimiento sigue siendo requerido.

2.4.5. Caracteristicas del Consentimiento Valido

  • Libre: Sin checkbox pre-marcado, usuario debe activar explicitamente
  • Especifico: Separar consentimiento para cada finalidad
  • Informado: Aviso de privacidad leido antes de consentir
  • Inequivoco: Firma electronica (biometria) como evidencia

2.4.6. Flujo de Consentimiento

sequenceDiagram
    participant U as Usuario
    participant A as App MedTime
    participant B as Backend

    U->>A: Inicia registro
    A->>U: Muestra Aviso de Privacidad
    U->>A: Lee y acepta (checkbox)
    A->>U: Solicita consentimiento datos salud
    Note over A: Pantalla dedicada, texto claro
    U->>A: Firma electronica (biometria)
    A->>U: Solicita consentimiento transferencia USA
    Note over A: Explica E2E, datos cifrados
    U->>A: Acepta transferencia (checkbox)
    A->>B: Registra consentimientos con timestamp
    B->>B: Genera hash de aceptacion
    B-->>A: Confirmacion
    A->>U: Registro completado

2.4.7. Registro de Consentimientos

{
  "consent_record": {
    "user_id": "uuid",
    "consents": [
      {
        "type": "terms_of_service",
        "version": "2.0",
        "granted_at": "2025-01-15T10:30:00Z",
        "ip_address_hash": "sha256(...)",
        "method": "checkbox"
      },
      {
        "type": "sensitive_health_data",
        "version": "1.5",
        "granted_at": "2025-01-15T10:31:00Z",
        "method": "biometric_signature",
        "biometric_hash": "sha256(...)"
      },
      {
        "type": "international_transfer",
        "destination": "AWS us-east-1",
        "granted_at": "2025-01-15T10:32:00Z",
        "method": "explicit_checkbox"
      }
    ],
    "integrity_hash": "sha256(all_consents)"
  }
}

2.5. Notificacion de Vulneraciones (Art. 20)

ANALISIS ZERO-KNOWLEDGE: Dado que MedTime implementa arquitectura zero-knowledge donde el servidorNO tiene acceso a datos de salud ni a claves de cifrado, la probabilidad de una vulneracion que requiera notificacion regulatoria essignificativamente reducida.

2.5.1. Evaluacion de Probabilidad de Notificacion (Arquitectura Zero-Knowledge)

2.5.2. Que tiene el servidor MedTime (y puede ser comprometido)

Dato en Servidor Sensibilidad Si se Compromete Notificacion Requerida
Blind Index (email_hash) Baja Hash no reversible sin salt NO (no es dato personal)
Blobs cifrados E2E Ninguna AES-256-GCM indescifrable NO (datos inutilizables)
Metadata (timestamps) Baja Revela patrones de uso EVALUAR (si permite inferencias)
Tamano de blobs Baja Revela cantidad de datos NO (no identificable)
Tier de suscripcion Baja Dato comercial NO (no sensible)

2.5.3. Que NO tiene el servidor (y NO puede ser comprometido desde servidor)

Dato Protegido Ubicacion Riesgo de Breach Servidor
Email en texto claro Solo cliente CERO
Nombre de usuario Solo cliente (E2E) CERO
Lista de medicamentos Solo cliente (E2E) CERO
Dosis y horarios Solo cliente (E2E) CERO
Master Key del usuario Dispositivo (Secure Enclave) CERO
Recovery Key Usuario (offline) CERO

2.5.4. Conclusion de Probabilidad

PROBABILIDAD DE NOTIFICACION OBLIGATORIA:

Breach del servidor MedTime:        ~5% (solo si metadata revela info significativa)
Breach de AWS (infraestructura):    ~2% (datos siguen cifrados E2E)
Compromiso de codigo fuente:        ~10% (si revela vulnerabilidades explotables)
Ataque a dispositivo individual:    Variable (responsabilidad del usuario)

COMPARACION CON ARQUITECTURA TRADICIONAL:
Servidor tradicional con datos en claro: 95%+ probabilidad de notificacion
Servidor MedTime zero-knowledge:         <10% probabilidad de notificacion

2.5.5. Criterios de Notificacion LFPDPPP (Adaptados a Zero-Knowledge)

Escenario Datos Comprometidos Notificar Autoridad Notificar Usuario Plazo
Breach BD con solo blobs E2E Blobs ilegibles NO Informativo N/A
Breach con blind index expuesto Hashes de email NO* Informativo N/A
Breach con metadata de uso Timestamps, patrones EVALUAR Si significativo 72h
Compromiso de Split-Key server-side N/A (no existe) N/A N/A N/A
Compromiso global_salt (Blind Index) Potencial correlacion EVALUAR Si, preventivo 72h
Ataque exitoso a dispositivo individual Datos de 1 usuario NO (no es breach de MedTime) Si (al afectado) Inmediato

*El blind index (HMAC-SHA256) sin el global_salt no permite reconstruir el email

2.5.6. Ventaja del Zero-Knowledge vs E2E Tradicional

ARQUITECTURA ZERO-KNOWLEDGE MEDTIME:

Lo que el atacante obtiene en breach de servidor:
+-----------------------+-------------------+------------------------+
| Dato                  | Formato           | Utilidad para Atacante |
+-----------------------+-------------------+------------------------+
| user_id               | UUID opaco        | Ninguna                |
| email_hash            | HMAC-SHA256       | Ninguna sin salt       |
| encrypted_profile     | AES-256-GCM blob  | NINGUNA (indescifrable)|
| encrypted_medications | AES-256-GCM blob  | NINGUNA (indescifrable)|
| encrypted_notes       | AES-256-GCM blob  | NINGUNA (indescifrable)|
| tier                  | "free/pro/perfect"| Minima                 |
| last_sync_timestamp   | ISO 8601          | Minima                 |
+-----------------------+-------------------+------------------------+

DIFERENCIA CLAVE CON E2E TRADICIONAL:
- E2E tradicional: Servidor tiene clave para descifrar (para busquedas, etc.)
- Zero-Knowledge: Servidor NUNCA tuvo ni tendra la clave

IMPLICACION REGULATORIA:
Si el servidor nunca pudo ver los datos, un breach del servidor
NO PUEDE exponer datos que nunca estuvieron ahi.

2.5.7. Flujo de Respuesta a Incidentes (Mexico)

flowchart TD
    A[Incidente Detectado] --> B{Involucra datos personales?}
    B -->|No| C[Cerrar incidente tecnico]
    B -->|Si| D{Datos cifrados comprometidos?}
    D -->|Solo blobs cifrados| E[Riesgo: BAJO]
    D -->|Claves expuestas| F[Riesgo: ALTO]
    D -->|Metadatos expuestos| G[Riesgo: MEDIO]

    E --> H[Documentar internamente]
    F --> I[Activar protocolo LFPDPPP]
    G --> J{Afectacion significativa?}

    J -->|No| H
    J -->|Si| I

    I --> K[Notificar INAI < 72h]
    I --> L[Notificar usuarios afectados]
    I --> M[Forzar rotacion de claves]

    K --> N[Seguimiento con INAI]
    L --> O[Canal atencion afectados]
    M --> P[Invalidar sesiones activas]

    H --> Q[Reporte interno]
    N --> Q
    O --> Q
    P --> Q
    Q --> R[Post-mortem 7 dias]

2.5.8. Clasificacion de Incidentes

Nivel Descripcion Tiempo Respuesta Notificar INAI Ejemplo
P1-Critico Breach con datos expuestos 1h Si (<72h) Acceso no autorizado a BD con claves
P2-Alto Intento de breach detectado 4h Evaluar Multiples logins fallidos masivos
P3-Medio Anomalia de seguridad 24h No Patron de acceso inusual
P4-Bajo Evento informativo 72h No Actualizacion de parche

2.6. Roles de Proteccion de Datos

2.6.1. Responsable del Tratamiento (Art. 3-XIV)

Aspecto Requisito Implementacion MedTime
Designacion Persona fisica o moral [Entidad Legal MedTime]
Funciones Decidir sobre tratamiento CTO (interino v1.0)
Publicacion En aviso de privacidad Aviso + seccion "Contacto"
Contacto Canal de derechos ARCO privacidad@medtime.com

2.6.2. Responsable de Seguridad (NOM-024)

Aspecto Requisito Implementacion MedTime
Rol Garantizar seguridad informacion CTO (rol dual v1.0)
Funciones Implementar controles, incidentes Documentado en org chart
Reporte A direccion general Reporte mensual
Contacto Interno y externo seguridad@medtime.com

Nota v1.0: En etapa inicial, CTO asume rol dual. Se designara rol dedicado cuando equipo supere 15 empleados o ARR supere $100k USD.

2.7. Transferencias de Datos (Art. 36-37)

2.7.1. Transferencias Autorizadas v1.0

Destino Tipo Dato Base Legal Salvaguarda
AWS us-east-1 (USA) Todos (cifrados) Consentimiento explicito E2E + contrato
DrugBank (Canada) Solo codigos medicamento Contrato comercial Sin PII

2.7.2. Flujo de Datos Transfronterizos

flowchart LR
    subgraph Mexico ["Mexico"]
        U[Usuario MX]
        D[Dispositivo<br/>Datos en claro]
    end

    subgraph Transito ["En Transito"]
        T[TLS 1.3<br/>Datos cifrados E2E]
    end

    subgraph USA ["Estados Unidos"]
        AWS[AWS us-east-1<br/>Solo blobs cifrados]
    end

    subgraph Canada ["Canada"]
        DB[DrugBank API<br/>Solo codigos]
    end

    U --> D
    D -->|Cifrado local| T
    T -->|Consentimiento| AWS
    AWS -->|Consulta sin PII| DB
    DB -->|Respuesta| AWS
    AWS -->|Blob cifrado| T
    T -->|Descifrado local| D

3. NOM-024-SSA3-2012 - Sistemas de Informacion en Salud

3.1. Requisitos de Seguridad

ID Requisito Implementacion Estado
NOM024-001 Interoperabilidad FHIR R4 (MTS-FHIR-001) OK
NOM024-002 Seguridad de informacion E2E + MFA + Audit OK
NOM024-003 Confidencialidad Cifrado E2E, clave usuario OK
NOM024-004 Disponibilidad Modo offline (MTS-OFF-001) OK
NOM024-005 Integridad Hash verification, checksums OK
NOM024-006 Trazabilidad Audit log 6 anos OK
NOM024-007 Respaldo Backups cifrados horarios OK
NOM024-008 Recuperacion Modo offline como DR OK

3.2. Interoperabilidad FHIR R4

3.2.1. Recursos Soportados

Recurso FHIR Uso MedTime Operaciones
Patient Datos del usuario Read, Search
Medication Catalogo medicamentos Read, Search
MedicationRequest Prescripciones Create, Read
MedicationStatement Historial tomas Create, Read
AllergyIntolerance Alergias Create, Read, Update

3.2.2. Formatos de Exportacion

Formato Uso Especificacion Estado
FHIR JSON API principal application/fhir+json OK
CSV Exportacion simple RFC 4180 OK
JSON Legacy/debug application/json OK
PDF/A Documentos legibles ISO 19005-1 OK

3.3. Continuidad de Negocio

3.3.1. Estrategia v1.0: Modo Offline como DR

Decision del Director: El modo offline implementado (MTS-OFF-001) es la estrategia primaria de continuidad para v1.0.

Metrica Objetivo v1.0 Implementacion
RTO Inmediato (offline) App funciona sin conexion
RPO Ultima sincronizacion Datos locales siempre disponibles
Disponibilidad Variable Dependiente de app stores

3.3.2. Justificacion

POR QUE MODO OFFLINE ES SUFICIENTE PARA v1.0:

1. ARQUITECTURA E2E
   - Datos de salud estan en dispositivo del usuario
   - Servidor es solo backup cifrado
   - Usuario siempre tiene acceso a SUS datos

2. CASO DE USO
   - MedTime no es sistema critico para vida
   - Alertas funcionan offline (alarmas locales)
   - Usuario puede consultar medicamentos sin conexion

3. COSTO-BENEFICIO
   - Multi-region active-active: +$2k/mes
   - Beneficio marginal dado E2E
   - Recursos mejor invertidos en features

4. ESCENARIO DE FALLA
   - AWS us-east-1 cae
   - Usuario abre app: FUNCIONA (modo offline)
   - Sincroniza cuando servicio restaura
   - Cero impacto en uso diario

3.3.3. Procedimientos Minimos

Evento Deteccion Respuesta Comunicacion
API no disponible Health check cada 5 min Auto-switch a offline Banner in-app
Sync fallida Retry exponencial Cola local Indicador "pendiente sync"
Servicio restaurado Health check OK Sync automatica Banner "reconectado"

3.4. Requisitos de Audit Trail

Campo Descripcion Retencion
Timestamp ISO 8601 con zona 6 anos
User ID Hash del usuario 6 anos
Action CRUD + tipo 6 anos
Resource Tipo de dato 6 anos
IP Hash Hash de IP origen 6 anos
Device ID Identificador dispositivo 6 anos

4. NOM-004-SSA3-2012 - Expediente Clinico

4.1. Aplicabilidad

IMPORTANTE: MedTimeNO constituye un expediente clinico oficial. Es una herramienta de apoyo personal al paciente.

4.2. Requisitos Aplicables (como herramienta complementaria)

ID Requisito Implementacion Nota
NOM004-001 Identificacion paciente Datos perfil Solo para uso personal
NOM004-002 Integridad registros Checksums, E2E Datos del usuario
NOM004-003 Confidencialidad Cifrado E2E Maximo nivel
NOM004-004 Conservacion 6 anos o vida cuenta Segun LFPDPPP
NOM004-005 Acceso a informacion Exportacion FHIR Para compartir con medico 
AVISO IMPORTANTE

MedTime es una aplicacion de apoyo personal para el seguimiento
de tratamientos farmacologicos. NO sustituye:

- El expediente clinico oficial
- La consulta medica profesional
- El criterio del profesional de salud

Los datos exportados pueden utilizarse como informacion
complementaria para su medico, pero no tienen valor legal
como expediente clinico bajo NOM-004-SSA3-2012.

5. COFEPRIS - Requisitos de Recetas Mexico

5.1. Vigencia de Recetas

Tipo de Receta Vigencia Surtimientos Alerta MedTime
Receta simple 1 ano Multiples 30 dias antes
Antibioticos 7 dias 1 Inmediata
Controlada Grupo I 30 dias 1 Estricta, no resurtible
Controlada Grupo II 30 dias Hasta 3 Tracking surtimientos
Controlada Grupo III 30 dias Hasta 3 Tracking surtimientos

5.2. Requisitos de Almacenamiento

ID Requisito Implementacion Estado
COF-001 Imagen legible Cifrado E2E, alta resolucion OK
COF-002 Retencion 7 anos Politica automatica OK
COF-003 Datos prescriptor Campo obligatorio OCR OK
COF-004 Datos medicamento Validacion vs catalogo OK
COF-005 Fecha emision Validacion vigencia OK

5.3. Advertencias al Usuario

Escenario Mensaje Severidad
Receta proxima a vencer "Tu receta de [X] vence en [N] dias" Warning
Receta vencida "Esta receta ya no es valida" Error
Medicamento controlado "Medicamento controlado. Consulta tu medico" Info
Surtimientos agotados "Has agotado los surtimientos" Warning
Antibiotico > 7 dias "Receta de antibiotico vencida" Error

6. Arquitectura Zero-Knowledge E2E

6.1. Principio Fundamental

ZERO-KNOWLEDGE = EL SERVIDOR NO SABE

MedTime implementa cifrado extremo-a-extremo donde:

1. Datos de salud se cifran EN EL DISPOSITIVO del usuario
2. El servidor almacena SOLO blobs cifrados (AES-256)
3. La clave de descifrado NUNCA sale del dispositivo
4. Ningun empleado de MedTime puede acceder a PHI
5. En caso de breach, datos son INUTILIZABLES

6.2. Implicaciones de Cumplimiento

Requisito Tradicional Con E2E Beneficio
BAA con proveedores Simplificado No hay "acceso" a PHI
Breach notification Minimizada Datos cifrados = bajo riesgo
Auditoria de accesos Metadatos only No hay acceso a contenido
Solicitudes ARCO Usuario tiene datos Acceso inmediato
Eliminacion Borrar clave = fin Irrecuperable garantizado

6.3. Que Puede Ver el Servidor (Exposicion Minimizada - INV-008, INV-010)

PRINCIPIO DE MINIMA EXPOSICION: El servidor SOLO almacena lo estrictamente necesario para operacion, y NUNCA en texto claro cuando es evitable.

6.3.1. Datos de Identificacion (INV-008: Blind Index)

Tipo de Dato Formato en Servidor Servidor Ve Real Uso
Email Blind Index(HMAC-SHA256) NO - Solo hash Busqueda para login
Telefono Blind Index(HMAC-SHA256) NO - Solo hash Busqueda para MFA
Nombre Blob E2E(AES-256-GCM) NO Ninguno - solo cliente
Fecha Nacimiento Blob E2E(AES-256-GCM) NO Calculos client-side
Foto Perfil Blob E2E(AES-256-GCM) NO Solo cliente

6.3.2. Implementacion Blind Index (INV-008)

email_blind_index = HMAC-SHA256(global_salt_HSM, normalize(email))

6.3.3. Datos de Salud (E2E Obligatorio)

Tipo de Dato Formato en Servidor Servidor Ve Cliente Ve
Medicamentos Blob E2E NUNCA Si
Dosis Blob E2E NUNCA Si
Horarios Blob E2E NUNCA Si
Historial tomas Blob E2E NUNCA Si
Recetas (imagen) Blob E2E NUNCA Si
Notas medicas Blob E2E NUNCA Si

6.3.4. Datos Anonimizados para Analytics (INV-010)

Dato Anonimizado Servidor Ve Vinculable a Usuario Tecnica
Categorias terapeuticas agregadas Conteos NO Generalizacion
Patrones de adherencia (agregados) Distribucion NO Differential Privacy LDP
Frecuencia de uso por region Estadisticas NO k-Anonymity (k>=1000)

6.3.5. Arquitectura de Anonimizacion (INV-010)

FLUJO DE DATOS ANONIMIZADOS:

Dispositivo:                          Servidor:
+------------------+                  +------------------+
| 1. Generalizar   |                  | Solo recibe:     |
|    Metformina -> |   Token efimero  | - Categoria      |
|    Antidiabetico |  -------------> | - Region general |
| 2. Aplicar LDP   |   (sin user_id)  | - Periodo        |
| 3. Gen token     |                  | NO recibe:       |
|    efimero       |                  | - user_id        |
+------------------+                  | - device_id      |
                                      | - IP             |
                                      +------------------+

Ver INV-010: Anonimizacion de Medicamentos

6.3.6. Metadata Operativa (Sin Datos Sensibles)

Metadata Servidor Ve Sensibilidad Justificacion
Tier suscripcion Si Baja Facturacion
Ultimo sync timestamp Si Baja Operacional
Tamano de blobs Si Baja Storage management
Cantidad de entries Si Baja Limites por tier
Version de esquema Si Ninguna Migraciones
Plataforma (iOS/Android) Si Ninguna Debugging

6.3.7. Resumen de Exposicion del Servidor

+=====================================================+
|           SERVIDOR MEDTIME VE                        |
+=====================================================+
| DATOS DE IDENTIFICACION:                             |
|   - email_hash (Blind Index)     [NO REVERSIBLE]    |
|   - phone_hash (Blind Index)     [NO REVERSIBLE]    |
|                                                      |
| DATOS DE SALUD:                                      |
|   - encrypted_blob               [INDESCIFRABLE]    |
|                                                      |
| METADATA:                                            |
|   - tier, timestamps, sizes      [NO SENSIBLE]      |
|                                                      |
| ANALYTICS:                                           |
|   - datos_anonimizados           [NO VINCULABLES]   |
+=====================================================+
| SERVIDOR MEDTIME NUNCA VE:                          |
|   - Email real                                       |
|   - Nombre del usuario                              |
|   - Lista de medicamentos                           |
|   - Dosis, horarios, historial                      |
|   - Imagenes de recetas                             |
|   - Notas medicas                                   |
|   - NINGUN DATO PHI EN TEXTO CLARO                 |
+=====================================================+

6.4. Flujo de Datos E2E (Corregido)

6.4.1. Flujo de Busqueda y Registro de Medicamento

sequenceDiagram
    participant U as Usuario
    participant D as Dispositivo
    participant A as API MedTime
    participant CAT as Catalogo Medicamentos
    participant DB as Base Datos

    Note over U,D: BUSQUEDA DE MEDICAMENTO
    U->>D: Busca medicamento (manual o escaneo OCR)
    D->>A: Consulta catalogo (solo nombre parcial)
    A->>CAT: Busqueda por texto
    CAT-->>A: Lista de matches (sin PHI)
    A-->>D: Opciones de medicamento
    D->>U: Muestra resultados
    U->>D: Selecciona medicamento + configura dosis

    Note over U,D: CIFRADO LOCAL
    D->>D: Construye objeto medicamento
    D->>D: Cifra con clave local (AES-256-GCM)

    Note over D,A: SOLO DATOS CIFRADOS EN TRANSITO
    D->>A: Envia blob cifrado via TLS 1.3
    A->>A: Valida formato y tamano, NO contenido
    A->>DB: Almacena blob opaco
    Note over DB: Servidor NUNCA ve medicamento real

    Note over D: ANONIMIZACION PARALELA (Opcional)
    D->>D: Generaliza: Metformina -> "Antidiabetico"
    D->>D: Aplica Differential Privacy (LDP)
    D->>D: Genera token efimero (sin user_id)
    D->>A: Envia datos anonimizados (batch, con jitter)
    Note over A: Para analytics, SIN vinculo a usuario

6.4.2. Flujo de Recuperacion de Datos

sequenceDiagram
    participant U as Usuario
    participant D as Dispositivo
    participant A as API MedTime
    participant DB as Base Datos

    Note over U,D: SOLICITUD DE DATOS
    D->>A: Solicita blobs del usuario
    A->>DB: Recupera blobs por user_id
    DB-->>A: Blobs cifrados (opacos)
    A-->>D: Blobs cifrados via TLS 1.3
    Note over A: API solo ve blobs, no contenido

    Note over D: DESCIFRADO LOCAL
    D->>D: Descifra con clave local
    D->>U: Muestra datos en claro

6.4.3. Anonimizacion en Transito (INV-010)

Cuando el usuario opta por contribuir a analytics (opt-in o default con opt-out):

PROCESO DE ANONIMIZACION EN TRANSITO:

1. GENERALIZACION (en dispositivo):
   "Metformina 850mg" -> "Antidiabetico Oral"
   "CDMX"             -> "Centro Mexico"
   "45 anos"          -> "40-50"

2. DIFFERENTIAL PRIVACY (en dispositivo):
   - Randomized Response con epsilon=2.0
   - 88% reporta valor real
   - 12% reporta valor aleatorio

3. DESVINCULACION (en dispositivo):
   - Token de sesion efimero (NO user_id)
   - NO device_id
   - NO IP en payload

4. BATCH + JITTER (en dispositivo):
   - Acumular eventos por 72h
   - Agregar delay aleatorio (0-6h)
   - Enviar lote sin correlacion temporal

5. TRANSMISION (TLS 1.3):
   - Datos llegan al servidor
   - Servidor NO puede vincular a usuario
   - Solo procesa para estadisticas agregadas

6.5. Gestion de Claves (Actualizado INV-008)

Aspecto Implementacion V1.0
Generacion Derivada de password + salt (Argon2id preferido, PBKDF2 fallback)
Almacenamiento Secure Enclave (iOS) / Keystore (Android)
Arquitectura Split-Key (Shamir 2-of-3)
Componentes Key_Password + Key_Device + Key_Recovery
Backup Obligatorio: Recovery Key 24 palabras BIP39
Rotacion Por solicitud del usuario o compromiso detectado
Perdida total Datos irrecuperables (by design, con advertencia clara)

6.5.1. Split-Key Architecture (INV-008)

Master Key = Reconstruct(2 de 3 shares):
  - Share A: KDF(user_password, salt)  -> Para login normal
  - Share B: Secure Enclave/Keystore   -> Dispositivo actual
  - Share C: 24 palabras BIP39         -> Recovery Key offline

Login normal:     Share A + Share B
Nuevo dispositivo: Share A + Share C
Olvido password:  Share B + Share C (si tiene dispositivo)

Ver INV-008: Cifrado de Perfil e Identificacion

7. Requerimientos de Implementacion

7.1. Autenticacion y Autorizacion

[REQ-SEC-001] MFA obligatorio para acceso a datos de salud
[REQ-SEC-002] Soporte biometria (huella, Face ID)
[REQ-SEC-003] Timeout de sesion: 15 minutos inactividad
[REQ-SEC-004] Bloqueo cuenta: 5 intentos fallidos
[REQ-SEC-005] Re-autenticacion para acciones sensibles

7.2. Cifrado

[REQ-CIF-001] Datos reposo: AES-256-GCM
[REQ-CIF-002] Datos transito: TLS 1.3 minimo
[REQ-CIF-003] Rotacion claves servidor: 90 dias
[REQ-CIF-004] Datos salud: E2E obligatorio
[REQ-CIF-005] Backups: Cifrado con claves separadas

7.3. Auditoria (Zero-Knowledge - INV-011)

PARADOJA RESUELTA: En arquitectura zero-knowledge, el servidor no puede ver los datos pero SI puede auditar acciones mediantemetadata + hashes de integridad + timestamps verificables. Ver INV-011: Auditoria Zero-Knowledge.

7.3.1. Arquitectura de Audit Log Zero-Knowledge

UBICACION DE AUDIT LOGS:

OPCION A: LOG LOCAL ANONIMIZADO (Recomendado V1.0)
+------------------+
| Dispositivo      |
| - Log cifrado E2E|
| - Usuario puede  |
|   exportar       |
| - Backup en blob |
|   cifrado        |
+------------------+

OPCION B: LOG EN SERVIDOR (Solo metadata)
+------------------+
| Servidor         |
| - Solo metadata  |
| - SIN PHI        |
| - Hash de blobs  |
| - Timestamps     |
+------------------+

ESTRATEGIA V1.0: Combinacion de ambos
- Log local completo (cifrado E2E)
- Log servidor solo metadata (para compliance)

7.3.2. Requerimientos de Auditoria Actualizados

[REQ-AUD-001] Log de metadata de acciones (SIN contenido PHI)
[REQ-AUD-002] Campos ANONIMIZADOS: user_hash, accion, timestamp, resource_id (NO contenido)
[REQ-AUD-003] Logs inmutables: Hash chain + RFC 3161 timestamps
[REQ-AUD-004] Retencion: 6 anos (HIPAA) / 5 anos (LFPDPPP)
[REQ-AUD-005] Exportable: Usuario puede exportar SU log completo descifrado
[REQ-AUD-006] NUEVO: Log local cifrado E2E para auditoria personal
[REQ-AUD-007] NUEVO: Hash de integridad por operacion
[REQ-AUD-008] NUEVO: Counters ciegos para deteccion de anomalias

7.3.3. Estructura de Audit Log en Servidor (Sin PHI)

{
  "event_id": "evt_2025120510300001",
  "timestamp": "2025-12-05T10:30:00.000Z",
  "event_type": "DATA_ACCESS",
  "actor": {
    "user_hash": "sha256:usr_7f8a9b2c...",
    "session_id": "ses_abc123",
    "device_id": "dev_xyz789",
    "ip_hash": "sha256:ip_hash..."
  },
  "action": {
    "verb": "READ",
    "resource_type": "MEDICATION_BLOB",
    "resource_id": "blob_def456",
    "result": "SUCCESS"
  },
  "integrity": {
    "resource_hash": "sha256:abc123...",
    "prev_log_hash": "sha256:prev...",
    "chain_hash": "sha256:chain..."
  }
}
// NOTA: En NINGUN momento se registra nombre de medicamento,
// dosis, ni ningun dato PHI. Solo IDs opacos y hashes.

7.3.4. Log Local del Usuario (Cifrado E2E)

El usuario tiene acceso a un log completo de sus propias acciones, cifrado con su clave:

{
  "user_audit_log": {
    "encrypted_with": "user_master_key",
    "entries": [
      {
        "timestamp": "2025-12-05T10:30:00Z",
        "action": "CREATED_MEDICATION",
        "details": {
          "medication_name": "Metformina 850mg",
          "configured_dose": "1 tableta",
          "schedule": "08:00, 20:00"
        }
      }
    ]
  }
}
// Este log SI contiene detalles, pero esta cifrado E2E
// Solo el usuario puede verlo/exportarlo

7.3.5. Verificacion de Integridad (Hash Chain)

ESTRUCTURA DE HASH CHAIN (INV-011):

Entry[0]:
  sequence: 0
  event_hash: SHA-256(event_data)
  prev_hash: "GENESIS"
  chain_hash: SHA-256(0 + timestamp + event_hash + "GENESIS")

Entry[N]:
  sequence: N
  event_hash: SHA-256(event_data)
  prev_hash: Entry[N-1].chain_hash
  chain_hash: SHA-256(N + timestamp + event_hash + prev_hash)

VERIFICACION:
- Si se modifica Entry[K], todos los hashes K+1..N se invalidan
- Anchors RFC 3161 cada hora para prevenir truncacion
- Auditoria puede verificar integridad sin ver contenido

7.3.6. Timestamps Verificables (RFC 3161)

FLUJO DE TIMESTAMPING:

1. Cada hora: batch_hash = SHA-256(log_entries_ultima_hora)
2. Enviar a TSA (Timestamping Authority): DigiCert/GlobalSign
3. Recibir timestamp_token firmado por TSA
4. Almacenar token como prueba de existencia en ese momento
5. En auditoria: verificar firma TSA + recalcular hash

COSTO ESTIMADO: ~$0.05/timestamp = ~$36/mes para batches horarios

Ver referencia completa: INV-011: Auditoria Zero-Knowledge

7.4. Privacidad

[REQ-PRI-001] Consentimiento explicito para datos salud
[REQ-PRI-002] Consentimiento granular por categoria
[REQ-PRI-003] Historial de consentimientos
[REQ-PRI-004] Revocacion en cualquier momento
[REQ-PRI-005] Notificacion de cambios en politicas

7.5. Derechos del Titular

[REQ-DER-001] Exportacion de todos los datos
[REQ-DER-002] Eliminacion completa de cuenta
[REQ-DER-003] Solicitudes ARCO en < 20 dias habiles
[REQ-DER-004] Confirmacion de eliminacion
[REQ-DER-005] Correccion de datos personales

8. Programa de Auditorias v1.0

8.1. Frecuencia Adaptada para Startup

Tipo Frecuencia v1.0 Responsable
Revision de accesos Mensual CTO
Auditoria interna Semestral CTO + Externo
Vulnerability scan Mensual (automatizado) DevOps
Pentest Anual Firma externa

8.2. Alcance Auditoria Interna

  • Cumplimiento LFPDPPP (aviso, ARCO, consentimiento)
  • Controles NOM-024 (seguridad, trazabilidad)
  • Revision de logs de auditoria
  • Verificacion de backups
  • Gestion de accesos

8.3. Programa Security Awareness

Componente Frecuencia Formato
Induccion seguridad Onboarding 1h presentacion
Phishing awareness Trimestral Email + quiz
Actualizacion politicas Anual Documento + firma
Manejo incidentes Semestral Simulacro

9. Matriz de Cumplimiento v1.0 (Mexico)

9.1. Resumen de Estado

LFPDPPP:     |||||||||| 95%  [CUMPLE]
NOM-024:     |||||||||  92%  [CUMPLE]
NOM-004:     |||||||||| 100% [N/A - No somos expediente clinico]
COFEPRIS:    |||||||||  90%  [CUMPLE]
------------------------------------------------
MEXICO v1.0: |||||||||  94%  CUMPLIMIENTO ALTO

9.2. Por Funcionalidad

Funcionalidad LFPDPPP NOM-024 COFEPRIS
Autenticacion OK OK N/A
Cifrado E2E OK OK OK
Audit Trail OK OK OK
Consentimiento OK N/A N/A
ARCO OK N/A N/A
Exportacion OK OK N/A
Recetas N/A N/A OK

10. Referencias

10.1. Documentos Internos MedTime

10.2. Investigaciones Incorporadas

INV Titulo Temas Principales
INV-008 Cifrado de Perfil e Identificacion Blind Index, Split-Key Shamir 2-of-3, Argon2id KDF
INV-009 Consentimiento Datos de Salud Sentencia TJUE C-21/23, Consentimiento explicito
INV-010 Anonimizacion de Medicamentos Differential Privacy LDP, Randomized Response, k-Anonymity
INV-011 Auditoria Zero-Knowledge Metadata logging, Hash Chain, RFC 3161 Timestamps

10.3. Fuentes Externas

  • LFPDPPP - Ley Federal de Proteccion de Datos Personales en Posesion de los Particulares
  • NOM-024-SSA3-2012 - Sistemas de informacion de registro electronico para la salud
  • NOM-004-SSA3-2012 - Del expediente clinico
  • COFEPRIS - Lineamientos para prescripcion y dispensacion
  • INAI - Guia para elaborar avisos de privacidad (2016)

Documento generado por SpecQueen (ComplianceDrone + ConsistencyDrone) - La especificacion funcional ES el sistema. Version 2.1.0 - Iteracion 13 - Correcciones OBS-024 a OBS-030 con arquitectura Zero-Knowledge E2E