No es una hoja de ruta ni un catálogo de intenciones — cada fila de esta página está desplegada en producción real (app.careflow.cl) y verificada de punta a punta. Pensada para responder rápido preguntas técnicas de cualquier licitación de trazabilidad clínica o software de salud, no solo la actual.
El motor de trazabilidad en sí — la parte que reemplaza la planilla.
| Componente | Qué hace | Estado |
|---|---|---|
| Motor de estados por patología | Máquina de estados configurable — etapas, responsables y reglas de transición propias por patología, no una lista fija. | Implementado |
| Editor low-code visual | Configura workflows, etapas y formularios sin tocar código fuente. | Implementado |
| Formularios obligatorios por etapa | Bloquea el avance de un caso si falta un campo clínico requerido. | Implementado |
| Motor de alertas | Umbrales configurables por organización; job automático de vencimiento de plazos. | Implementado |
| Dashboards en tiempo real | Cumplimiento de plazos, desglose por patología, GES / No GES. | Implementado |
| Detección de cuellos de botella | Snapshots periódicos por etapa + detección de anomalías, no solo un promedio. | Implementado |
| Exportación completa | 16 entidades maestras y transaccionales, en CSV, XLSX o JSON, en cualquier momento. | Implementado |
Cómo entran y salen datos de otros sistemas.
| Componente | Qué hace | Estado |
|---|---|---|
| API RESTful | API HTTP documentada, autenticación JWT + control de acceso por rol. | Implementado |
| HL7 FHIR R4 | Recursos estándar Patient, Condition, EpisodeOfCare, Organization; CapabilityStatement público en /fhir/metadata. | Implementado |
| OAuth 2.0 client_credentials | Acceso máquina a máquina con scopes acotados por integración (lectura y un scope de escritura deliberadamente angosto). | Implementado |
Construido desde el modelo de datos, no agregado como parche.
| Componente | Qué hace | Estado |
|---|---|---|
| LDAP / Active Directory | Autenticación institucional por organización, probada contra un directorio real. | Implementado |
| 2FA obligatorio | TOTP forzado para los 4 roles (ADMIN, GESTOR, CLÍNICO, VISOR), sin excepción. Bloqueo automático tras intentos fallidos, mismo criterio que la contraseña. | Implementado |
| Cabeceras de seguridad HTTP | Content-Security-Policy, X-Frame-Options y el resto del set estándar, en backend y frontend — no delegado por default al proveedor de hosting. | Implementado |
| RBAC + aislamiento multi-tenant | Permisos por rol clínico; aislamiento entre organizaciones verificado (recursos anidados devuelven 404 entre organizaciones distintas). | Implementado |
| Cifrado de datos de paciente | AES-256-GCM en campos sensibles (nombres, RUT, fecha de nacimiento) antes de tocar la base. | Implementado |
| TLS en tránsito | Certificado real emitido automáticamente, verificado en el dominio de producción. | Implementado |
| Clasificación de la información | Registro de 5 niveles de sensibilidad de datos (Ley 19.628 + ISO 27001). | Implementado |
| Auditoría | Cada request autenticada queda registrada — quién, qué ruta, con qué resultado — retención de 5 años. | Implementado |
| Escaneo de vulnerabilidades | npm audit + CodeQL (SAST) automatizados en CI, en cada cambio y además semanalmente. | Implementado |
Qué pasa cuando algo falla — probado de verdad, no solo documentado.
| Componente | Qué hace | Estado |
|---|---|---|
| Respaldos diarios | Volcado completo en streaming a almacenamiento externo — nunca carga la base entera en memoria — retención de 90 días. | Implementado |
| Restauración probada | Simulacro real: base vaciada por completo y restaurada desde el respaldo, integridad verificada fila por fila contra un conteo independiente. | Verificado |
| Simulacro de caída | Servicio de producción detenido de forma controlada y medido con monitoreo automático. | RTO real: 90s |
Cómo está armado por debajo.
| Componente | Qué hace | Estado |
|---|---|---|
| Multi-tenant | Aislamiento de datos por organización desde el modelo de datos, no por convención de aplicación. | Implementado |
| Ambientes separados | Producción, QA y demo pública corren sobre bases de datos completamente independientes. | Implementado |
| Base de datos | PostgreSQL con branching — copias aisladas para pruebas y demos sin tocar datos reales. | Implementado |
| Hosting | Backend y frontend en infraestructura productiva real, con dominio propio y TLS — no un entorno de prueba local. | Implementado |
Qué se lleva el cliente al terminar.
| Componente | Qué hace | Estado |
|---|---|---|
| Entrega de datos | Exportación del 100% de los datos maestros y transaccionales, sin costo adicional. | Implementado |
| Acta de entrega verificable | Manifiesto con conteo por entidad + checksum criptográfico (SHA-256) del archivo entregado. | Implementado |
| Certificado de eliminación de datos | Documento formal generado a partir del resultado real del borrado — qué se eliminó, cuántas filas de cada entidad — no una plantilla genérica. | Implementado |
Nada en esta página es una promesa de roadmap. Antes de marcar algo como "en producción", se ejecutó contra un ambiente real: se apagó el servicio para medir cuánto tarda en recuperarse, se vació una base y se restauró desde el respaldo, se corrió un escaneo de seguridad de verdad — no se dio por bueno porque el código "debería funcionar".
El RTO: 90s de la tabla de continuidad operacional no es una estimación de manual — sale de apagar careflow-api en producción y cronometrar la recuperación con monitoreo automático hasta que volvió a responder.