UDENTIVA incorpora a la propia arquitectura la madurez de procesos que se exige al software sanitario. Esta página expone, con pruebas, nuestro ciclo de vida de desarrollo, los niveles de capacidad SPICE / ISO-IEC 15504, nuestros mecanismos de registro y control continuo de errores, nuestros criterios de versión y seguridad, y nuestro historial de desarrollo.
Base legal: Reglamento sobre Sistemas de Gestión de Información Sanitaria (n.º de norma 39682), art. 6 y art. 20: requisito de certificación de calidad del software (CMMI/SPICE).
La definición de procesos, la implementación y los productos de trabajo trazables están estructurados; los mecanismos de medición cuantitativa, prevención de defectos y mejora continua operan en producción. La declaración oficial de nivel de capacidad está sujeta a una evaluación independiente (appraisal).
SPICE evalúa los procesos con niveles de capacidad del 0 al 5. UDENTIVA está estructurado para cumplir las expectativas de los Niveles 1-3 en cuanto a definición de procesos, implementación y productos de trabajo trazables; para los Niveles 4-5 se operan mecanismos de medición cuantitativa y mejora continua. La declaración oficial de nivel está sujeta a evaluación independiente.
Los mecanismos de control cuantitativo y mejora continua correspondientes a los Niveles 4-5 se operan a continuación con sus evidencias (medición en vivo, registro de errores/CAPA, historial de despliegues).
Cada área de proceso se corresponde con una implementación concreta y una evidencia auditable en UDENTIVA. El proceso no es un documento, es código en funcionamiento.
| Área de proceso | Aplicación UDENTIVA | Prueba |
|---|---|---|
| ENG.1 Extracción de requisitos | Mapa de fases + definición de requisitos por slice vertical (vertical slice); el contrato de proyecto UDENTIVA.md fija los requisitos. | UDENTIVA.md (REGLAS DE ORO), especificación técnica 02_tech_spec/, mapa de fases/módulos |
| ENG.4 Diseño de software | Monolito modular; los paquetes de contexto (context) no comparten sus tablas entre sí; comunicación mediante interface; servicio externo = adapter. | regla de límites internal/{identity,patient,billing,export,...}; ADR-001..008 |
| ENG.5 Construcción de software | SQL explícito (sqlc, sin ORM); context como primer parámetro en cada función; envoltura de errores %w; dinero = numeric. | override de tipo en sqlc.yaml (numeric→string), db/queries/*.sql, gofmt/golangci-lint |
| ENG.6 Integración de software | Cadena loopback PHP(BFF) ↔ Go ↔ PostgreSQL ↔ Redis; única superficie pública. | web/core/ApiClient, salud de componentes /healthz (db+redis) |
| ENG.7 Pruebas de software | Prueba de aislamiento cross-tenant (la más crítica), idempotencia, conflicto de citas, precisión monetaria, 2FA/OTP, vector TOTP RFC6238, QR (verificación OpenCV+ISO). | internal/integration/*_test.go, platform/totp/totp_test.go, go test ./... |
| SUP.1 Aseguramiento de calidad | Cada PR debe cumplir las REGLAS DE ORO; lint limpio; si la prueba de aislamiento está en rojo en CI, no hay merge. | golangci-lint, Definition of Done kontrol listesi |
| SUP.8 Gestión de configuración | Control de versiones Git (branch core); versionado de esquema secuencial con goose; los artefactos de build se respaldan. | git, goose_db_version tablosu, .tools/deploy yedekleri |
| SUP.9 Resolución de problemas | Registro de auditoría de solo adición (append-only) + outbox de correo/SMS (registro de cada envío) + disciplina de respaldo/rollback de despliegue. | audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback |
| SUP.10 Gestión de solicitudes de cambio | Cada cambio de esquema es una nueva migración numerada; reversible (goose Down); aprobación del clasificador de despliegue. | db/migrations/0001..0027, +goose Up/Down |
| MAN.3 Gestión de proyecto | Entrega por slice vertical (cada slice funciona de extremo a extremo); notas de traspaso de sesión. | super-devam.md, faz tablosu (DoD per dilim) |
| MAN.6 Medición | Verificación de salud, medición de capacidad, métricas de envío de correo/SMS, volumen de auditoría, telemetría de eventos en vivo. | /healthz, panel de Monitoreo de Procesos y Calidad (evento/error/despliegue/KPI) |
Las responsabilidades están divididas en capas; la autoridad del dominio reside en un único punto y está aislada mediante loopback. El navegador solo ve el BFF ligero y nunca puede acceder directamente a la capa de dominio ni de datos.
| Capa | Responsabilidad y seguridad | Ubicación |
|---|---|---|
| Sunum (BFF) | PHP 8.4 — BFF ligero: sesión, render, CSRF, enrutamiento. SIN regla de negocio/DB. Única superficie pública (IIS:443). | web/ |
| Uygulama / Domain | Monolito modular en Go — la ÚNICA autoridad del dominio. RBAC, reglas de negocio, transacciones. Solo escucha en 127.0.0.1. | api/internal/ |
| Veri | PostgreSQL — cada tabla con tenant_id + RLS FORCE; SQL explícito (sqlc), parametrizado. Dinero en numeric. | api/db/ |
| Caché / Cola | Redis — sesión, idempotencia, bloqueo distribuido, cola asynq (SMS/e-fatura). | platform/redisx |
| Nesne Depolama | Compatible con S3 — archivos grandes (radiografías) presigned/stream; el blob nunca está en la DB. | platform/storage |
| Servicio externo (adapter) | e-Fatura, SMS (NetGSM), correo electrónico (SMTP), (más adelante e-Nabız/MEDULA/DICOM) — abstraídos detrás de una interface. | internal/notify |
La medición no es una declaración, sino un sistema en funcionamiento. Todas las operaciones se cuentan en vivo (éxito/fallo), los errores de producción quedan capturados en un registro permanente y el siguiente marco de KPI se vincula a acciones periódicas. Las fuentes de datos son tablas reales: event_counter (contador de operaciones en vivo), error_log (registro permanente de errores), deploy_log (registro de despliegues).
| Área de medición | KPI | Objetivo | Fuente de datos | Periodo | Acción |
|---|---|---|---|---|---|
| Seguridad de aislamiento de tenant | cross-tenant test fail | 0 | CI / izolasyon testi | her PR | Bloqueo de merge |
| Error de producción | error abierto (5xx/panic) | 0 | error_log (persistente) | continuo/en vivo | RCA + CAPA zorunlu |
| Tasa de éxito de operaciones | success / toplam event | ≥ 99 % | event_counter (en vivo) | continuo/en vivo | Causa raíz en caso de caída |
| Tiempo de resolución | MTTR (resolución prom.) | ↓ tendencia decreciente | error_log (resolved) | mensual | Trend incelemesi |
| Fiabilidad de despliegue | tasa de rollback | < %5 | deploy_log | 30 días | Rollback review |
| Seguridad de identidad | 2FA/OTP kritik olay | 0 | audit + event_counter | mensual | Endurecimiento |
| Fiabilidad de mensajería | SMS/e-posta failure | ↓ baja | *_outbox | diario | Revisión de proveedor |
| Preparación de restauración | éxito de prueba de restauración | %100 | DR test (hedef) | trimestral | Actualizar runbook |
Cada error de producción pasa por un ciclo de análisis de causa raíz (RCA) y acción correctiva/preventiva (CAPA) estándar; la repetición del mismo error se evita mediante control de regresión y seguimiento de tendencias.
El error de producción (5xx/panic) se captura automáticamente → error_log persistente (al repetirse la misma firma, count++, tendencia de defectos).
Se determinan el nivel (error/panic), el impacto y el número de repeticiones; la prevalencia se mide con los contadores de eventos fallidos.
En el panel de Monitoreo de Procesos se realiza y se registra el análisis de causa raíz.
Se define y se registra una acción correctiva + acción preventiva (código, prueba, regla de migración, control de seguridad).
Se agrega una prueba/regla que impide la repetición del mismo error; se monitorea con telemetría continua.
Las tendencias de KPI (MTTR, tasa de errores, rollback) se evalúan periódicamente; para errores recurrentes se abre una acción a nivel de proceso.
La esencia del Nivel 5 de SPICE: registro continuo de errores, mantenimiento bajo control, prevención de defectos y mejora continua. UDENTIVA opera estos mecanismos en producción.
El audit_log inmutable (append-only) registra de forma persistente cada operación crítica; email_outbox/sms_outbox registran cada envío (status, attempts, error). Ningún evento se pierde silenciosamente.
Sobre de error consistente {error:{code,message}}; el error interno/stack nunca se filtra. Antes de cada despliegue, respaldo del binary + web; ante una caída, rollback en segundos con bin/server.exe.bak-*.
Arquitectura fail-closed: sin contexto RLS, 0 filas; la idempotencia impide la doble operación; el dinero numeric hace imposible el error de float; la whitelist (dataset de exportación) previene la inyección SQL. Los errores se previenen desde el diseño.
Los componentes críticos se verifican con dos métodos independientes: vector de prueba TOTP RFC6238, decodificación OpenCV cv2 + codeword de referencia ISO/IEC 18004 para el QR, prueba de aislamiento cross-tenant.
En cada sesión: auditoría de seguridad → hallazgos → endurecimiento (p. ej. se agregó RBAC de fase2/fase3, 2FA, Export API). La memoria institucional se preserva con notas de proceso (super-devam.md).
Una nueva exigencia regulatoria (Vista VEM) se convierte directamente en funcionalidad de producto y en evidencia; los cambios normativos se monitorean continuamente y se registran en el mapa de cumplimiento.
Una única base de código, restricción por flags, sin fork.
Versión trazable en la capa de esquema, fuente, despliegue y API.
Todo el proceso de desarrollo bajo control de versiones; cada despliegue es reversible (rewind/rollback).
La seguridad no es una función, es la propia arquitectura. Reglas innegociables cuya vulneración supone el rechazo del PR:
El sistema se construyó con cortes verticales, cada uno funcionando de principio a fin. A continuación se muestran las fases y la cronología de los recientes trabajos de seguridad/regulación.
pgx+sqlc, goose, prueba RLS fail-closed, WithTenantTx, middleware de sesión, login+RBAC, auditoría, loopback PHP↔Go, base asynq, health.
CRUD de pacientes + prueba de aislamiento cross-tenant → Citas (exclusion constraint + Redis lock) → Odontograma/Plan de tratamiento (FDI, append-only) → Cobro/Cuenta corriente/Caja (derive, idempotente) → adapter e-Fatura (fast-follow) → Inventario → Radiografía (S3) → Recordatorio por SMS (asynq backoff).
Tier de operador de plataforma (súper-admin) (X-Platform-Key, plano de identidad separado); gestión de tenants, modelo de suscripción/facturación, medición de capacidad, editor de versiones legales, reCAPTCHA, ajustes de NetGSM.
i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.
Primitiva OTP compartida; restablecimiento de contraseña + magic-link + activación de cuenta (SMTP real); núcleo de SMS NetGSM; auth pública multi-tenant; gestión de usuarios de clínica.
TOTP (RFC6238) + códigos de respaldo; QR OBLIGATORIO (independiente de externos, qr.js limpio de CSP; verificado de forma independiente con OpenCV+ISO); verificación de teléfono por SMS (consentimiento KVKK).
Vista VEM (Modelo de Datos Mínimo) 12 vistas de exportación + Export API (definido por SuperUser, bloqueado por tenant, fail-closed); mapa de Normativa y Cumplimiento; revisión de contratos legales 100 % orientada a la normativa.
Centro de Soporte con seguimiento de tickets; documentación de procesos SPICE (esta página); auditoría de seguridad continua + endurecimiento.
Para obtener información detallada sobre arquitectura, seguridad y cumplimiento normativo, contacte con nuestro equipo.
We use cookies necessary for core functionality; analytics and marketing cookies are enabled only with your consent. Política de cookies