PROYECTO FINAL DE CICLO SUPERIOR | DAM

Plataforma de Tickets para Clínicas de Salud Mental

Sistema de gestión de consultas con trazabilidad normativa

David Gallardo Suárez · Digitech FP Málaga · 5 de junio de 2026

Abrir demo en vivo

01

BLOQUE 1 · CONTEXTO

El problema actual de las clínicas pequeñas

Las consultas llegan por email, teléfono, en persona, WhatsApp...
No hay un registro único: cada solicitud queda en un sitio distinto
Dos personas pueden gestionar el mismo caso sin saberlo
No se puede saber correctamente el estado de una solicitud
Existe riesgo legal si se tratan datos clínicos

02

BLOQUE 1 · PROPUESTA

La solución: una plataforma web con tickets

INC

Número único

Cada consulta se convierte en un ticket con formato INC-YYYYMMDD-XXXX

🔗

Acceso por token

El paciente accede mediante un enlace seguro, sin crear cuenta y sin recordar contraseña

📋

Dashboard médico

El doctor gestiona todos los tickets desde un panel unificado

🧾

Registro de acciones

Queda registrado quién hizo qué, cuándo y sobre qué ticket

🔍

Auditoría

El registro es completo y exportable para revisar evidencias

03

BLOQUE 2 · IMPLEMENTACIÓN

Stack tecnológico

PyPython

Elegido por su ecosistema de seguridad y porque el ciclo lo prepara para Java, no al revés

FAFastAPI

Rendimiento async, validación automática con Pydantic y documentación OpenAPI sin configuración extra

SASQLAlchemy

ORM maduro que permite cambiar de BD sin tocar código. Equivale a Hibernate en Java

AlAlembic

Migraciones versionadas que se ejecutan solas al arrancar el contenedor

DBMariaDB

Sustituto directo de MySQL, sin coste de licencia y compatible con el stack del ciclo

DcDocker Compose

Entorno reproducible en cualquier máquina con un solo comando. Evita el "en mi máquina funciona"

J2Jinja2

Motor de plantillas del ecosistema Python. Equivale a JSP/Thymeleaf, pero sin compilación intermedia

Bcbcrypt

Estándar para hash de contraseñas. Incluye sal automática y coste configurable

Iditsdangerous

Librería de Flask para firmar cookies y tokens sin depender de sesiones en BD

OTOTP por email

Segundo factor sin instalar apps. Usa secrets de la stdlib + smtplib, cero dependencias externas

AoAuditoría append-only

Tabla de solo inserción. Nada se borra ni modifica. Trazabilidad forense real

HcHash chain

Cada evento contiene el hash del anterior. Detectar manipulación es inmediato

04

BLOQUE 2 · DEMO EN VIVO

Pasos del flujo

1

Captura

El paciente rellena el formulario público

2

Creación

El sistema crea un ticket, estado abierto, enlace de confirmación

3

Acceso del paciente

El paciente entra desde el enlace. Sin cuenta ni contraseña

4

Doctor

Login con usuario, contraseña y segundo factor OTP

5

Respuesta

El doctor ve el detalle, responde y cambia el estado

6

Cierre

El ticket se cierra, el paciente recibe aviso

05

BLOQUE 3 · SEGURIDAD

Controles de seguridad implementados y verificados

Auth

bcrypt para passwords
Sesiones firmadas
MFA OTP por email: 10 min, 5 intentos

Tokens

SHA-256 para lookup
AES-256-GCM para cleartext
Token aleatorio
Caducidad 72h con sliding window

Datos

Cifrado AES-256-GCM
Emails sin contenido clínico
Rate limit en login y OTP
Hash chain en auditoría

06

BLOQUE 4 · CUMPLIMIENTO NORMATIVO

Marcos normativos de referencia

Marco	Aplica	Justificación
RGPD	OK	Privacidad y seguridad del tratamiento
LOPDGDD	OK	Ley Orgánica de Protección de Datos Personales y Garantía de los Derechos Digitales
Ley 41/2002	OK	Conservación mínima de documentación clínica
ENS	OK	Esquema Nacional de Seguridad
CCN-STIC 221/817	OK	Criptografía e incidentes
OWASP	OK	Seguridad web aplicativa
NIST SSDF	OK	Desarrollo seguro de software
ISO 27799	OK	Seguridad de la información sanitaria
LGS	OK	Ley General de Salud

07

BLOQUE 5 · VALOR DIFERENCIAL

Cuatro elementos no vistos en clase

Token paciente

Acceso sin cuenta, SHA-256 + AES-256-GCM, caducidad revocable con sliding window

MFA OTP email

Doble factor para doctores, 6 dígitos, 10 min de validez, sin app externa

Compliance as Code

Marcos normativos, controles trazados, evidencias y auditoría

RGPD desde diseño

Estrategias AEPD, emails sin datos clínicos, privacidad por defecto

08

BLOQUE 6 · REFLEXIÓN

Conclusiones y aprendizaje personal

Lo que aprendí

Lo más difícil fue priorizar y decidir qué quedaba fuera
Aprender a justificar cada decisión técnica fue lo más enriquecedor
Pensar en compliance as code cambia la forma de diseñar software
La seguridad no es una capa añadida: afecta a todas las fases del diseño
El RGPD no es solo burocracia: es un marco que guía decisiones técnicas

Mejora futura

Integración con un gestor centralizado de claves (KMS)
Añadir un segundo método MFA basado en TOTP
Automatizar copias de seguridad cifradas
Rotación periódica automática de claves
Conexión con herramientas de terceros

Gracias por su atención

Ir a la demo

David Gallardo Suárez | TFG DAM 2025-2026 | Digitech FP Málaga