EPPA DPA — Flujo de kinesiólogo¶

Borrador pendiente de aprobación

Este documento es un borrador operativo para revisión legal, institucional y del responsable LABIS/UCA. No constituye asesoramiento legal, no prueba cumplimiento GDPR/HIPAA/SOC2, no autoriza uso clínico comercial y no reemplaza el contrato o DPA firmado por las partes.

1. Identidad del documento¶

Campo	Valor
Documento	EPPA Data Processing Agreement — flujo de kinesiólogo
ID	EPPA-DPA-KIN-001
Versión	0.1 (draft)
Estado	Borrador — pendiente de revisión legal/institucional
Producto	EPPA, frontend Next.js y backend FastAPI bajo `fronts/eppa/`
Alcance	Uso de investigación clínica por kinesiólogo, fisioterapeuta o investigador entrenado
Documentos vinculados	`00-overview.md`, `30-gdpr-dpia.md`, `50-secdev-checklist.md`, `91-non-device-disclaimer.md`, `auth-model-decision-record.md`

2. Partes y roles¶

Las partes deben completarse por despliegue antes de publicar o firmar este DPA.

Rol	Parte	Estado
Responsable / controller	TBD: LABIS UCA o institución clínica/investigadora que determina fines y medios	Pendiente
Encargado / processor	TBD: operador técnico que aloja EPPA o presta infraestructura	Pendiente
Subencargados	TBD: hosting, almacenamiento de objetos, SMTP, backup, monitoreo	Pendiente
Responsable científico	TBD: investigador principal o responsable LABIS	Pendiente
Contacto privacidad	TBD: correo institucional de privacidad o DPO	Pendiente
Contacto seguridad	TBD: correo institucional de seguridad	Pendiente

Si EPPA se ejecuta localmente en una workstation del laboratorio sin proveedor externo, el despliegue puede no requerir un encargado externo. Esa decisión debe quedar documentada por el responsable del protocolo.

3. Finalidad y límites operativos¶

EPPA se usa para documentar y analizar fotografías posturales estáticas en un protocolo de investigación. El kinesiólogo carga una imagen, marca puntos anatómicos, ejecuta cálculos validados contra MATLAB y exporta resultados para revisión profesional.

Límites obligatorios:

Uso de investigación solamente; EPPA no está aprobado, registrado ni habilitado como dispositivo médico.
Los resultados son informativos y requieren interpretación por profesional matriculado.
EPPA no debe usarse como base única o principal para diagnóstico, tratamiento, certificación laboral, aptitud deportiva, decisión legal, decisión aseguradora o decisión asistencial.
Los ejemplos, fixtures, capturas y payloads publicados deben ser sintéticos o anonimizados. No deben contener pacientes reales, secretos, credenciales, tokens, payloads clínicos privados ni datos propietarios de instituciones.

La redacción autorizada del aviso de no-dispositivo está en 91-non-device-disclaimer.md.

4. Datos tratados¶

Categoría	Ejemplos	Sensibilidad	Estado actual
Imagen postural / radiografía o fotografía	Imagen anterior, posterior, lateral derecha, lateral izquierda	Dato de salud; puede identificar por rostro, cuerpo, metadatos o nombre de archivo	Cargada por el operador en el navegador; no se envía en los endpoints estándar de cálculo
Identificador de paciente/estudio	Código pseudónimo, texto ingresado por el kinesiólogo, ID importado desde `.mat`	Dato personal si puede vincularse a una persona	Puede quedar en `sessionStorage`, exports o nombre de archivo local
Marcadores anatómicos	Coordenadas `x/y`, LRV, calibración, regiones analizadas	Dato de salud derivado	Enviado a la API de análisis para cálculo
Resultados clínicos derivados	Ángulos, distancias, diagnósticos cualitativos, CSV/PDF/imagen exportada	Dato de salud derivado	Devuelto al navegador y exportado por el operador
Datos de cuenta del profesional	Email, hash de contraseña, rol, invitación, tokens de sesión	Dato personal del profesional	Modelo de auth local en progreso; ver decisión SEC-001
Logs técnicos y de auditoría	Timestamp UTC, actor, método, ruta, status, duración	Dato técnico; puede ser personal si identifica usuario o sesión	Logs estructurados sin payload clínico

5. Flujo de datos actual¶

Paciente en sitio de investigación
        |
        v
Imagen capturada por el operador
        |
        v
Navegador EPPA del kinesiólogo
  - carga imagen en memoria del navegador
  - conserva estado de trabajo en sessionStorage
  - coloca marcadores y calibraciones
        |
        | POST JSON: marcadores, calibración, región
        v
FastAPI EPPA
  - calcula métricas posturales
  - registra evento técnico sin payload clínico
  - responde JSON de resultados
        |
        v
Navegador / export local
  - CSV, PDF o imagen generada por el operador

Los endpoints estándar /api/anterior/*, /api/posterior/*, /api/lateral/* y /api/analyze/* reciben coordenadas, calibración y parámetros de análisis. No reciben la imagen completa en el flujo estándar de cálculo.

Los endpoints que sí pueden recibir archivos o imagen deben tratarse como mayor riesgo:

Endpoint / flujo	Datos transmitidos	Condición operativa
`/api/anonymize`	Imagen y marcadores para generar imagen anonimizada	Permitido solo si no se registran payloads ni identificadores crudos; revisar retención por despliegue
`/api/detect-markers`	Archivo de imagen y vista	Requiere revisión de retención, tamaño, MIME y auditoría antes de uso clínico amplio
`/api/upload-mat`	Archivo `.mat` con marcadores y posible ID de paciente	Usar solo con archivos sintéticos o aprobados por protocolo; no publicar ejemplos reales
Export CSV/PDF/imagen	Resultados y posible identificador pseudónimo	Queda bajo custodia del operador/institución exportadora

6. Autenticación, acceso y auditoría¶

La postura vigente está definida en auth-model-decision-record.md (SEC-001, aceptada el 2026-05-24):

El nginx basic auth compartido se acepta solo como control transitorio para un operador LABIS o workstation supervisada.
Para operación multiusuario o con pacientes vinculables se requiere auth por usuario antes del uso clínico de investigación amplio.
El modelo local de auth/invitaciones debe terminarse y aplicarse en la frontera de rutas/API antes de presentar EPPA como software con auditoría individual.
Las llamadas de análisis deben registrar timestamp UTC, actor, método, ruta, tipo de análisis, status y duración.
Los logs no deben incluir radiografías, coordenadas de marcadores, IDs de paciente, access tokens, refresh tokens, reset tokens, contraseñas ni payloads clínicos.

EPPA ya registra llamadas de análisis para /api/analyze/*, /api/anterior/*, /api/posterior/* y /api/lateral/*. El cliente envía X-EPPA-Session-ID; el servidor lo hashea antes de registrarlo. Cuando haya token de auth local válido, el servidor registra el ID de usuario en lugar de la sesión anónima.

7. Instrucciones al encargado¶

El encargado, si existe, solo puede tratar datos EPPA siguiendo instrucciones documentadas del responsable:

Alojar y operar la aplicación, API, base de datos y almacenamiento aprobados.
Proteger transporte, credenciales, logs, backups y exports conforme al DPIA.
No reutilizar imágenes, marcadores, resultados o logs para entrenamiento, analítica, soporte externo o demos sin instrucción escrita del responsable.
No copiar datos a entornos no aprobados.
No usar datos reales en issues, PRs, documentación, fixtures, capturas, reportes de prueba o ejemplos.
Notificar incidentes de seguridad o privacidad al responsable sin demora y con evidencia suficiente para contención.

8. Retención y eliminación¶

La retención definitiva se aprueba por despliegue en la DPIA y el protocolo de investigación. Hasta esa aprobación, los límites operativos son:

Dato	Retención propuesta	Dueño de aprobación
Imágenes clínicas originales	TBD por protocolo; referencia actual DPIA: 10 años o eliminación/anonimización irreversible según consentimiento	Responsable científico + legal/DPO
Marcadores y resultados	TBD por protocolo; referencia actual DPIA: 10 años	Responsable científico + legal/DPO
Exports locales	Definida por la institución que exporta y custodia el archivo	Institución clínica/investigadora
Logs de análisis	Sin payload clínico; retención pendiente hasta persistencia de auditoría	Responsable LABIS + seguridad
Logs web técnicos	Referencia actual DPIA: 90 días	Seguridad/operaciones
Invitaciones y cuentas	Duración de relación profesional + ventana de offboarding aprobada	Responsable de despliegue

La eliminación debe cubrir copias primarias, backups recuperables y exports bajo control del responsable. Si aplica una excepción de investigación, debe documentarse la pseudonimización o anonimización irreversible ofrecida al titular.

9. Seguridad y privacidad mínimas¶

Controles mínimos antes de operar con datos reales o vinculables:

TLS para todo tráfico fuera de localhost.
Secretos en variables de entorno, gestor de secretos o KMS; nunca en repo.
Cuentas nominadas para profesionales; no compartir credenciales cuando haya más de un usuario o datos vinculables.
Rotación de credenciales compartidas si se usa basic auth transitorio.
Logs sin payload clínico y con actor hasheado cuando no exista usuario.
Backups cifrados y restauración probada si hay persistencia de datos.
Control de acceso por rol y organización antes de operación multiinstitución.
Workstations con bloqueo de pantalla, disco cifrado y política de descarga para CSV/PDF/imagen.
Revisión explícita de /api/anonymize, /api/detect-markers y /api/upload-mat antes de habilitarlos en despliegues con pacientes reales.

10. Subencargados y transferencias¶

Cada despliegue debe completar esta tabla antes de publicar o firmar el DPA.

Subencargado	Servicio	Región	Datos tratados	Base contractual	Estado
TBD	Hosting app/API	TBD	Tráfico, logs, posible dato clínico derivado	Art. 28 DPA / contrato institucional	Pendiente
TBD	Base de datos	TBD	Cuentas, estudios, auditoría futura	Art. 28 DPA / contrato institucional	Pendiente
TBD	Almacenamiento de objetos	TBD	Imágenes, exports, backups futuros	Art. 28 DPA / SCC/TIA si aplica	Pendiente
TBD	SMTP	TBD	Email profesional, reset/invitación	Art. 28 DPA	Pendiente
TBD	Monitoreo	TBD	Logs técnicos sin payload clínico	Art. 28 DPA	Pendiente

No se debe habilitar transferencia internacional de datos personales o datos de salud sin base documentada, evaluación de transferencia cuando aplique y aprobación del responsable.

11. Gestión de solicitudes e incidentes¶

El responsable debe mantener procedimientos para:

Información y consentimiento del paciente antes de captura.
Acceso, rectificación, restricción, oposición, portabilidad y eliminación.
Retiro de consentimiento cuando sea la base legal.
Registro y clasificación de incidentes de seguridad.
Notificación al responsable, DPO/legal e institución dentro de los plazos aplicables.
Preservación de evidencia sin copiar payloads clínicos a sistemas no aprobados.

Los canales operativos (privacy@..., security@..., DPO, mesa de ayuda o equivalente) quedan pendientes por despliegue.

12. Aprobaciones pendientes¶

Este documento no queda publicado como DPA final hasta completar:

Aprobación	Responsable	Evidencia requerida	Estado
Revisión legal / DPA Art. 28 o equivalente	TBD	Firma, comentario de PR o acta institucional	Pendiente
Revisión DPO / privacidad	TBD	DPIA/ROPA actualizada y aprobada	Pendiente
Revisión responsable científico LABIS	TBD	Confirmación del protocolo y retención	Pendiente
Revisión seguridad/operaciones	TBD	Checklist de seguridad y arquitectura del despliegue	Pendiente
Revisión producto/regulatoria	TBD	Confirmación de disclaimer y límites de investigación	Pendiente

13. Evidencia de privacidad del repositorio¶

Este borrador no incluye datos reales de pacientes, secretos, tokens, credenciales, payloads clínicos propietarios, archivos .mat privados, radiografías ni fotografías clínicas. Los ejemplos usan nombres genéricos, placeholders TBD y rutas de código/documentación del repositorio.