NOM-024-SSA3-2012 — Matriz de Cumplimiento
Norma Oficial Mexicana: Sistemas de información de registro electrónico para la salud. Intercambio de información en salud.
Publicación DOF: 30 de noviembre de 2012
Aplicabilidad SINAPSIS: Todo el sistema — aplica como SIRES (Sistema de Información de Registro Electrónico para la Salud) que procesa expedientes clínicos y derivaciones médicas del IMSS.
Resumen Ejecutivo
| Sección | Requisitos | ✅ Cumple | 🟡 Parcial | ❌ Pendiente |
|---|
| §5 Generalidades (confidencialidad, integridad) | 9 | 7 | 2 | 0 |
| §6.3 SIRES (documentos, trazabilidad) | 4 | 3 | 1 | 0 |
| §6.4 Uso de estándares y catálogos | 3 | 3 | 0 | 0 |
| §6.5 Identificación de pacientes | 5 | 3 | 1 | 1 |
| Total | 21 | 16 (76%) | 4 (19%) | 1 (5%) |
§5 — Generalidades
"Los SIRES deben garantizar la confidencialidad de la identidad de los pacientes así como la integridad y confiabilidad de la información clínica."
| Requisito | Implementación SINAPSIS | Estado |
|---|
| Confidencialidad de identidad del paciente | JWT + RBAC dinámico. Solo usuarios autenticados con permiso read en el módulo correspondiente acceden a datos de pacientes. | ✅ |
| Integridad de información clínica | Soft delete universal (gorm.DeletedAt). Nunca se borra físicamente información de negocio. | ✅ |
| Medidas de seguridad contra uso ilícito | RBAC por perfil + unidad + privilegio. Auditoría de eventos en sec_audit_auth_event. | ✅ |
§5.4 — Manejo discreto y confidencial
"En todos los establecimientos de atención médica, la información contenida en los SIRES debe ser manejada con discreción y confidencialidad."
| Requisito | Implementación SINAPSIS | Estado |
|---|
| Información disponible solo al paciente, familiares o con autorización | Datos de paciente expuestos solo a usuarios con acceso a la unidad médica correspondiente (sec_user_unidades). | ✅ |
| Principios éticos de la práctica médica | Sistema no toma decisiones médicas; solo gestiona flujos administrativos. | — |
§5.6 — Conservación y disponibilidad de datos
"Los Prestadores de Servicios de Salud son responsables de conservar y mantener en condiciones adecuadas de operación sus SIRES."
| Requisito | Implementación SINAPSIS | Estado |
|---|
| Integridad y disponibilidad a través del tiempo | Backup automático diario mysqldump+gzip 23:55, retención 3 últimos (services/backup_service.go). | ✅ |
| Condiciones adecuadas de operación | Docker Compose con healthchecks; Nginx reverse proxy; Let's Encrypt TLS. | ✅ |
§5.8 — Trazabilidad en registros
"Los Prestadores de Servicios de Salud deben contar con trazabilidad en los registros que les permitan identificar y analizar situaciones."
| Requisito | Implementación SINAPSIS | Estado |
|---|
| Trazabilidad en operaciones | subr_solicitudes_detalle, inter_derivaciones_detalle, fac_movimientos — bitácora completa de cambios de estatus. | ✅ |
| Trazabilidad zona en facturas | Campos zona_* en fac_facturas_solicitudes (ADR-010). | ✅ |
| Trazabilidad de autenticación | sec_audit_auth_event — eventos de login, logout, cambio de contraseña. | ✅ |
§5.9 — Datos completos e inalterados
"Los datos e información contenidos en sus SIRES para la prestación de servicios de salud permanezcan completos e inalterados."
| Requisito | Implementación SINAPSIS | Estado |
|---|
| Inmutabilidad de documentos clínicos | Soft delete. Estatus de solicitudes y derivaciones solo avanzan (no retroceden sin registro en bitácora). | ✅ |
| Sin borrado físico de datos de negocio | Confirmado: gorm.DeletedAt en todas las entidades principales. | ✅ |
| Documentos CFDI inalterados | UUID y XML del CFDI se almacenan; no se modifican post-recepción. | 🟡 XML no se guarda actualmente, solo UUID y datos. |
§6.3 — SIRES
§6.3.1 — Interfaces de intercambio
"Los SIRES deben implementar interfaces de intercambio de información de acuerdo a lo especificado en las Guías y Formatos."
| Requisito | Implementación SINAPSIS | Estado |
|---|
| Interfaces para intercambio interinstitucional | ACCEDER (vigencia derechos) y SIAP (catálogos) vía SOAP intranet-connector. | ✅ |
| Actualización de implementación según Guías/Formatos | No aplica directamente — SINAPSIS es sistema interno, no punto de intercambio SNS. | — |
§6.3.4 — Documentos electrónicos estructurados
"Los SIRES deben registrar la información derivada de la prestación de servicios de salud en forma de documentos electrónicos estructurados e inalterables."
| Requisito | Implementación SINAPSIS | Estado |
|---|
| Documentos estructurados | Todas las entidades en MariaDB con esquema normalizado. JSON responses con envelope {data, meta, error}. | ✅ |
| Inalterabilidad | Soft delete + bitácora de movimientos. No se permite editar solicitudes/derivaciones aprobadas sin registro. | ✅ |
§6.4 — Uso de Estándares y Catálogos
§6.4.2 — Catálogos fundamentales
| Catálogo NOM-024 | Implementación SINAPSIS | Estado |
|---|
| CIE (Clasificación Internacional de Enfermedades) | Catálogo CIE-10 completo con búsqueda — tabla imss_cie10. Usado en inter_derivaciones_diagnosticos. | ✅ |
| CLUES (Clave Única Establecimientos de Salud) | Import async desde archivo oficial SSA — tabla imss_clues. Worker Go con canal buffered. | ✅ |
| CURP | Capturado en tabla pacientes. Búsqueda por CURP disponible. | 🟡 No se valida contra RENAPO. |
§6.5 — Identificación de Pacientes
§6.5.1 — CURP como atributo único de identificación
"Con fines de intercambio de información en salud, la CURP validada de acuerdo a los lineamientos emitidos por la Secretaría de Gobernación, debe ser el atributo de identificación única de personas."
| Requisito | Implementación SINAPSIS | Estado |
|---|
| CURP como identificador único | Campo curp en tabla pacientes. Búsqueda principal por CURP en ACCEDER. | ✅ |
| Validación CURP contra RENAPO | CURP obtenida de ACCEDER (IMSS valida internamente). No hay validación directa RENAPO desde SINAPSIS. | 🟡 Depende de ACCEDER |
| No autogeneración de CURP | El sistema no genera CURP. Se obtiene de ACCEDER o se captura manualmente. | ✅ |
§6.5.3 — Datos mínimos de identificación
La NOM-024 establece un conjunto mínimo de atributos para identificar personas (Tabla 1):
| Atributo NOM-024 | Campo SINAPSIS (pacientes) | Estado |
|---|
| CURP (requerido) | curp | ✅ |
| Primer apellido (requerido) | apellido_paterno | ✅ |
| Segundo apellido | apellido_materno | ✅ |
| Nombre (requerido) | nombre | ✅ |
| Fecha nacimiento (requerido) | fecha_nacimiento | ✅ |
| Sexo (requerido) | sexo | ✅ |
| Estado nacimiento | No almacenado explícitamente | ❌ |
| Municipio / Localidad residencia | No almacenado | — (no requerido para operación interna) |
| Folio institucional | nss (NSS IMSS) | ✅ |
| Tipo beneficiario | No almacenado | — |
Brecha B-02: SINAPSIS no almacena entidad federativa de nacimiento (EDONAC) de forma independiente. Esta información la posee ACCEDER/IMSS pero no se persiste en la tabla pacientes local.
Recomendaciones de Mejora
| # | Recomendación | Sección NOM | Esfuerzo |
|---|
| R-01 | Almacenar XML del CFDI completo o hash SHA-256 para trazabilidad de inalterabilidad | §5.9 | Medio |
| R-02 | Agregar campo edonac a tabla pacientes; poblar desde ACCEDER | §6.5.3 | Bajo |
| R-03 | Documentar procedimiento de validación CURP (vía ACCEDER como proxy RENAPO) | §6.5.1 | Bajo |
| R-04 | Auditoría de consultas a datos de pacientes (quién accede, cuándo) | §5.4 | Alto |