Vantus Medical · seguridad y auditoría
Aquí el dato no es confidencial por política: es sensible por ley, y la diferencia se paga.
El expediente clínico es el caso más exigente de protección de datos que existe en México: dato personal sensible, con consentimiento expreso y por escrito, y con una norma propia que dice qué tiene que contener y cuánto tiempo se conserva. Esta página enumera los controles del sistema, la evidencia que cada uno deja y la norma que lo pide.
Por qué un expediente clínico no es «un dato más»
En casi cualquier industria, proteger la información es una obligación general: aviso de privacidad, finalidad, medidas razonables. En salud no. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares clasifica los datos de salud como datos personales sensibles, y esa clasificación cambia tres cosas a la vez: el consentimiento tiene que ser expreso y por escrito, las medidas de seguridad tienen que ser reforzadas, y el daño que produce una fuga no admite remedio posterior. Una tarjeta se cancela; un diagnóstico, no.
Encima de eso, el expediente clínico tiene norma propia. La NOM-004-SSA3-2012 dice qué tiene que contener el expediente y cada una de sus notas, y fija su conservación. Y la NOM-024-SSA3-2012 —la que aplica a los sistemas de registro electrónico para la salud— pide, con esas palabras, integridad, autenticidad, confidencialidad, disponibilidad y trazabilidad. Ninguna de las cinco es una política: las cinco son propiedades que un sistema tiene o no tiene, y que se demuestran con registros.
Por eso esta página no describe una política de seguridad. Describe controles, y junto a cada control el registro que deja y la norma que lo pide. Lo que viene de la plataforma sobre la que el sistema corre lleva su cita en el expediente interno. Lo que es obligación de su establecimiento se dice con esas palabras: es del operador.
El control que no produce un renglón fechado no es un control: es una intención.
Lo primero que hay que corregir
La ley cambió, y con ella cambió la autoridad
Si su aviso de privacidad menciona al Instituto Nacional de Transparencia como la autoridad ante la que se ejercen los derechos de acceso, rectificación, cancelación y oposición, está desactualizado. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente se publicó en el Diario Oficial de la Federación el 20 de marzo de 2025, entró en vigor al día siguiente y fue reformada el 14 de noviembre de 2025. Sustituye a la ley de 2010, y la competencia pasó a la Secretaría Anticorrupción y Buen Gobierno.
Para un hospital esto no es un detalle de redacción. El aviso de privacidad es el documento con el que se acredita la base de licitud del tratamiento, y es el primero que pide cualquier verificación. Un aviso que nombra a una autoridad que ya no lo es se lee como lo que es: un documento que nadie revisó desde antes del cambio.
El marco que aplica a un expediente clínico en México
| Instrumento | Autoridad | Publicación | Qué obliga |
|---|---|---|---|
| Ley Federal de Protección de Datos Personales en Posesión de los Particulares | Secretaría Anticorrupción y Buen Gobierno | 20 de marzo de 2025; reforma del 14 de noviembre de 2025 | Aviso de privacidad, base de licitud, medidas de seguridad y atención de derechos. Los datos de salud son sensibles: consentimiento expreso y por escrito |
| NOM-004-SSA3-2012, del expediente clínico | Secretaría de Salud | 15 de octubre de 2012 | Contenido y organización mínimos del expediente y de cada nota, en todo establecimiento de atención médica, y su conservación |
| NOM-024-SSA3-2012, sistemas de información de registro electrónico para la salud | Secretaría de Salud · Dirección General de Información en Salud | 30 de noviembre de 2012 | Integridad, autenticidad, confidencialidad, disponibilidad y trazabilidad del registro; catálogos de codificación e intercambio de información |
| Modelo de certificación y estandarización de buenas prácticas en atención de servicios de salud, manual para hospitales, segunda edición | Consejo de Salubridad General | Manual aprobado el 5 de marzo de 2026; recepción de solicitudes desde el 6 de abril de 2026 | Estándares de calidad y seguridad del paciente que el hospital acredita para certificarse. Certifica establecimientos, no programas |
Fuente: Diario Oficial de la Federación y Consejo de Salubridad General · verificado al 27 de septiembre de 2026
Dos precisiones que conviene dejar por escrito porque circulan al revés. La primera: no existe una certificación oficial mexicana de expediente clínico electrónico que un programa pueda ostentar; lo que existe es la conformidad con la NOM-024, que se declara y se acredita ante la autoridad sanitaria. La segunda: la normativa estadounidense de portabilidad y responsabilidad de seguros de salud no aplica a un establecimiento mexicano que no trata información de salud protegida de aquel país. Venderla como requisito es vender una obligación inexistente.
Quién entra: autenticación y sesión
El acceso al sistema pasa por un servidor de autenticación propio que emite un token de sesión firmado. Las pantallas no hablan con la base de datos: hablan con una capa de servicios que exige ese token en cada llamada. El token es de vida corta y se renueva, de modo que una sesión olvidada en la estación de enfermería deja de servir por sí sola.
En un hospital esto importa por una razón que no es teórica: la estación de trabajo es compartida y el turno cambia. Un modelo donde la sesión no caduca es un modelo donde la bitácora dice que el doctor de la mañana consultó un expediente a las once de la noche. La bitácora sigue siendo correcta; lo que deja de ser cierto es la identidad.
El control de acceso, componente por componente
| Control | Qué hace | Dónde está la evidencia |
|---|---|---|
| Autenticación con protocolo de autorización abierto | Emite el token de sesión contra el directorio de usuarios; el resto de los servicios no autentica por su cuenta | Portal y ejecución del backend de la plataforma |
| Token firmado, de vida corta | Cada llamada al API viaja con el token; el token caduca y se renueva sin volver a pedir la contraseña | Vida del token y renovación desde la capa intermedia |
| Una sola puerta de entrada al dato | Controladores de API sobre una misma clase base: no hay acceso directo a la base desde la pantalla | 500 archivos de controlador, clase base |
| Cuenta de usuario con ciclo de vida propio | Solicitada, pendiente de aprobación, activa, suspendida y dada de baja; el alta con su rol y su alcance se aprueba, no se teclea | Motor · ciclo de vida de cuenta de usuario transcrito en la página de matrices de estado |
| Credenciales y accesos como entidad del modelo | El modelo de datos generado declara entidades propias para credenciales, registros de acceso e incidentes de seguridad | Motor · entidades credentials, access_logs e incidentes_seguridad del otro proyecto del dominio de salud |
Fuente: evidencia de plataforma de la casa y modelo de datos leído de la base del motor de la casa el 27 de septiembre de 2026, hora del propio servidor
La casa mantiene sus propios hallazgos de seguridad documentados con severidad y con el procedimiento para reproducirlos, dentro del repositorio técnico de la plataforma, y los trata como deuda con dueño y fecha (citado). Se dice aquí porque un proveedor que afirma no tener hallazgos no está diciendo que su programa sea seguro: está diciendo que no los busca.
Quién puede qué: perfiles y permisos por rol
El permiso no se resuelve escondiendo botones. Se resuelve en la capa de datos: el menú, las pantallas y las operaciones que un usuario ve se arman preguntando por su rol antes de dibujar nada. La plataforma tiene un procedimiento dedicado a eso, spGetMenuConfigurationbyRole, y el permiso vive en una tabla propia que cruza pantalla, funcionalidad y rol (permiso_pantalla_funcionalidad; el procedimiento). Los permisos tampoco se capturan a mano pantalla por pantalla: hay una tarea del motor que asigna permisos por rol y siembra los catálogos.
En un hospital los roles son los de la operación, no los de un organigrama de informática: médico tratante e interconsultante, enfermería de piso, de urgencias, de cuidados intensivos y de quirófano, admisión y caja, farmacia clínica y de almacén, laboratorio, imagen y patología, auditoría de cuentas, coordinación de siniestros, cuentas por cobrar, dirección médica, y los externos: el paciente y su familiar autorizado, el proveedor, el agente y el ajustador del tercero pagador.
Hay tres controles del sector que conviene nombrar aparte, porque son los que distinguen un sistema hospitalario de un gestor documental con perfiles. El acceso de emergencia con justificación, para el caso en el que negar el acceso mata: se concede, se registra y se revisa después. La visibilidad documento por documento frente al tercero pagador, que decide qué ve la aseguradora de un expediente de siniestro y qué no. Y la segregación entre quien pide y quien aprueba, que en el motor se ve como ausencia de una transición: en el ciclo de la cuenta de usuario no existe el paso directo de «solicitada» a «activa».
- Segregación de funciones donde importa. Quien captura la nota no es quien audita el acceso a los expedientes; quien administra el sistema no es quien aprueba el alta de una cuenta con su alcance.
- El portal externo es un rol, no una excepción. El dictaminador del tercero pagador entra con su propio usuario, ve el expediente del siniestro documento por documento y deja su rastro en la misma bitácora.
- El rol se ve en pantalla. El sistema abre con la vista puesta por el rol; no hay una pantalla genérica desde la que todos vean todo.
- El acceso de emergencia se audita, no se prohíbe. Un control que se puede saltar sin dejar rastro es peor que no tenerlo; uno que no se puede saltar nunca termina desactivado por la operación.
Un permiso que sólo existe en el manual se rompe el primer día que alguien se va de vacaciones.
Quién vio y quién modificó cada nota: la bitácora
En salud hay que registrar dos cosas distintas y muchos sistemas sólo registran una. La primera es quién modificó: el cambio, con su valor anterior y su valor nuevo. La segunda es quién vio: la consulta de un expediente ajeno es, en sí misma, el hecho auditable, porque el daño de un expediente filtrado no necesita que nadie lo haya modificado.
El motor de estados de la plataforma no deja cambiar un estado sin registrarlo. Cada transición pasa por una validación que comprueba el estado de origen, el estado de destino y el rol del usuario, y al ejecutarse escribe dos rastros: el historial de la entidad —con estado anterior y estado nuevo— y una bitácora transversal con la operación marcada como cambio de estado, el valor anterior y el valor nuevo. Las citas exactas son para la validación, para la de rol, para la ejecución, para el historial y para la bitácora.
Y el registro de consulta no es una aspiración: está en el modelo de datos generado. En el proyecto del expediente clínico digital del motor existe una entidad de bitácora cuyo propósito declarado es registrar las acciones críticas del sistema incluyendo los accesos a expedientes, y existe un caso de uso propio —auditar el acceso a registros clínicos— con su actor responsable. En el proyecto de agenda y citas clínicas, la entidad equivalente se describe como registro inmutable de todas las acciones críticas, y hay entidades separadas para el historial de cambios de la cita y del paciente.
La pregunta del auditor no es «¿tienen bitácora?». Es «enséñeme quién abrió este expediente y con qué motivo». Eso es una consulta, no una búsqueda.
Los dos rastros, y dónde están declarados
| Qué se registra | Dónde vive | Origen |
|---|---|---|
| Cambio de estado con valor anterior y valor nuevo | Historial de la entidad y bitácora transversal del motor de estados | Plataforma |
| Acceso a un expediente | Entidad de bitácora del proyecto del expediente clínico, con el acceso a expedientes nombrado en su propósito | Motor · entidad log_auditoria, otro proyecto del dominio de salud |
| Revisión periódica del acceso | Caso de uso «auditar acceso a registros clínicos», con actor responsable declarado | Motor · caso de uso del otro proyecto del dominio de salud |
| Historial de cambios de la cita y del paciente | Dos entidades separadas del modelo de datos, además de la bitácora general | Motor · entidades historial_cita e historial_paciente, otro proyecto del dominio de salud |
| Comentario obligatorio en transiciones sensibles | Columna de la propia matriz de transiciones, exigida al ejecutar | Plataforma |
| Evidencia obligatoria en transiciones sensibles | Archivo adjunto ligado a la transición, exigido al ejecutar | Plataforma |
Fuente: evidencia de plataforma de la casa y modelo de datos de los otros proyectos del dominio de salud leído de la base del motor de la casa el 27 de septiembre de 2026, hora del propio servidor
La plataforma genera además pantallas de auditoría como tipo propio —con indicadores arriba, línea de tiempo y rejilla de detalle, detecta campos de auditoría al generar cada pantalla y publica en la documentación del proyecto dos piezas que un auditor pide por su nombre: el modelo de seguridad con su matriz de permisos y la matriz de trazabilidad y auditoría.
Los controles, uno por uno, con su evidencia y su norma
Control · qué deja de registro · qué norma lo pide
| Control | Qué registro deja | Norma o exigencia que lo pide | Origen |
|---|---|---|---|
| Identidad en cada nota | Autor, fecha, hora y firma de la nota de evolución | NOM-004-SSA3-2012: contenido de cada nota del expediente | Norma · entidad nota_clinica del otro proyecto del dominio de salud, con firma en su propósito |
| Permiso por rol y por funcionalidad | Tabla de permiso pantalla-funcionalidad-rol y menú resuelto por rol | NOM-024-SSA3-2012: confidencialidad del registro electrónico | Plataforma |
| Bitácora de acceso al expediente | Usuario, expediente, acción y hora del acceso | NOM-024-SSA3-2012: trazabilidad · Ley Federal de Protección de Datos Personales en Posesión de los Particulares: medidas de seguridad reforzadas sobre datos sensibles | Motor · entidad log_auditoria, otro proyecto del dominio de salud |
| Bitácora de cambio de estado | Estado anterior, estado nuevo, valor anterior, valor nuevo, usuario, hora | NOM-024-SSA3-2012: integridad y autenticidad | Plataforma |
| Aviso de privacidad y consentimiento | Aceptación registrada con su fecha y su versión de aviso | Ley Federal de Protección de Datos Personales en Posesión de los Particulares: consentimiento expreso y por escrito sobre datos sensibles | Motor · entidades avisos_privacidad_aceptados y consentimientos_legales, otro proyecto del dominio de salud |
| Política de cifrado como dato del sistema | Política registrada y consultable, no un párrafo en un documento | Ley citada: medidas de seguridad · NOM-024: confidencialidad | Motor · entidad politicas_cifrado, otro proyecto del dominio de salud |
| Registro de incidentes de seguridad | Incidente con su clasificación y su seguimiento | Ley citada: deber de informar las vulneraciones al titular | Motor · entidad incidentes_seguridad, otro proyecto del dominio de salud |
| Conservación del expediente | El expediente permanece consultable después del alta | NOM-004-SSA3-2012: conservación mínima de cinco años contados a partir del último acto médico | Norma · el brochure tabula de cinco a diez años según el acto |
| Versionado de artefactos y de cambios | Respaldo del artefacto e instantánea de versión por cambio aplicado | Control de configuración y de versiones | Plataforma |
| Expediente documental del sistema | Matriz de controles, política de control de acceso, plan de continuidad y de recuperación, informe de auditoría de configuración | Lo que un auditor de sistemas pide antes de mirar la pantalla | Plataforma |
Fuente: NOM-004-SSA3-2012 y NOM-024-SSA3-2012 (Diario Oficial de la Federación, 15 de octubre y 30 de noviembre de 2012), Ley Federal de Protección de Datos Personales en Posesión de los Particulares (20 de marzo de 2025), evidencia de plataforma y modelo de datos del motor · verificado al 27 de septiembre de 2026
Diez controles, diez registros, diez orígenes. Eso es lo que se puede poner sobre la mesa en una visita de verificación.
Retención: cinco años, y el día que lo pidan
La NOM-004-SSA3-2012 fija dos obligaciones que suelen confundirse. Una es de propiedad y resguardo: el expediente es del establecimiento, que responde por su custodia y su confidencialidad. La otra es de conservación: el expediente se conserva por un plazo mínimo de cinco años contados a partir del último acto médico. El brochure del sistema tabula un rango de cinco a diez años según el acto, y esa diferencia no es capricho: hay actos cuya exposición médico-legal vive más que el mínimo de la norma, y el umbral lo fija su establecimiento por encima del piso legal, nunca por debajo.
Conservar es la parte fácil. La parte que quiebra a los archivos en carpetas es entregar: un expediente completo, ordenado, legible y con sus notas en el orden en que ocurrieron, el día que lo pide un paciente, un perito, una aseguradora o la autoridad. Guardar cinco años de papel es posible; entregar en una tarde cinco años de papel ordenado por episodio, no.
En el sistema, el expediente cerrado sigue siendo consultable y se arma en consulta, no en transcripción. Hay dos cosas que el sistema no puede hacer por usted y se dicen aquí sin adornos. La primera: decidir el periodo de retención cuando su criterio médico-legal pide más que el mínimo de la norma. La segunda: la baja controlada al final del periodo, que es una decisión del establecimiento y no una tarea programada que alguien deja corriendo.
Cifrado, respaldo, ambientes y control de versiones
Separar el ambiente donde se prueba del ambiente donde se opera no es una cortesía: es lo que evita que una corrección de un martes toque el expediente de un episodio cerrado el lunes. La plataforma separa la base de cada sistema generado —una base por sistema— y trata la creación del sitio, de la base y de los servicios como pasos con su propio registro.
Todo cambio aplicado sobre un sistema en operación pasa por una secuencia que incluye una comprobación previa, un respaldo del artefacto que se va a tocar, el cambio, el posproceso y una instantánea de versión con su número. Esa instantánea es lo que permite responder a la pregunta incómoda de un peritaje: «¿cómo estaba esta pantalla el 14 de marzo, cuando se capturó esa nota?».
Dicho con precisión, para que nadie lea de más: ese respaldo es el del cambio, no el respaldo corporativo de su base de datos. La política de respaldo, la prueba de restauración, el plan de recuperación ante desastres y la gestión de las llaves de cifrado son del operador. El sistema le entrega los documentos que esos planes necesitan como expediente —continuidad del negocio, recuperación ante desastres, ambientes, control de versiones, plan de despliegue—, pero no ejecuta su política por usted.
Quién responde por qué
| Asunto | De la plataforma | Del establecimiento |
|---|---|---|
| Autenticación y emisión de sesión | Servidor de autenticación y token firmado | Alta y baja de usuarios, y quién queda con qué rol y qué alcance |
| Permisos | Modelo de permiso por rol, pantalla y funcionalidad | La decisión clínica y administrativa: quién ve qué, y quién aprueba qué |
| Bitácora | El registro automático de cada transición y del acceso al expediente | Revisarla. Una bitácora que nadie lee es un archivo, no un control |
| Acceso de emergencia | El mecanismo: se concede, se registra y queda marcado | La revisión posterior de cada uso, y la consecuencia cuando no procedía |
| Aviso de privacidad y consentimiento | El registro de la aceptación con su fecha y su versión | Redactar el aviso, mantenerlo vigente y recabar el consentimiento expreso y por escrito |
| Conservación | El expediente sigue consultable y se arma en consulta | El periodo, cuando su criterio médico-legal pide más que el mínimo, y la baja controlada al final |
| Cifrado | El cifrado en tránsito y en reposo, y la política como dato del sistema | La custodia de las llaves y la decisión sobre dónde residen los datos |
| Respaldo y recuperación | Respaldo del artefacto en cada cambio aplicado, con versión | Política de respaldo, prueba de restauración y plan de recuperación |
| Ambientes | Base y servicios separados por sistema; despliegue registrado | Quién tiene acceso a cada ambiente y con qué credencial |
| Cumplimiento ante la autoridad | La evidencia, ordenada y entregable | Cumplir. La responsabilidad no es delegable a un programa |
Reparto de responsabilidad declarado · 27 de septiembre de 2026
El expediente de auditoría que el sistema deja
La plataforma sobre la que Vantus Medical corre no sólo genera la aplicación: genera el expediente técnico del sistema. El catálogo tiene 211 documentos en 18 secciones, sin huecos ni duplicados en el rango, definidos en código. Dos de esas secciones son exactamente lo que un auditor de sistemas pide antes de mirar la pantalla, y una tercera es la que pide el área jurídica.
La sección de seguridad de la información reúne quince documentos, entre ellos la matriz de controles de seguridad, la política de control de acceso, la de clasificación de la información, la de cifrado y protección de datos, el plan de respuesta a incidentes, el plan de continuidad del negocio y el de recuperación ante desastres. La de gestión de la configuración reúne diez, entre ellos el registro de elementos de configuración, el plan de control de versiones, el documento de ambientes y el informe de auditoría de configuración.
Las secciones del expediente que sostienen una auditoría de sistemas
| Sección | Documentos | Piezas que un auditor pide por su nombre |
|---|---|---|
| Seguridad de la información | 15 | Plan de seguridad, declaración de aplicabilidad, evaluación y tratamiento de riesgos, política de control de acceso, clasificación de la información, continuidad del negocio, recuperación ante desastres, cifrado y protección de datos, privacidad, respuesta a incidentes, evaluación de vulnerabilidades, seguridad en el desarrollo, matriz de controles, concienciación |
| Gestión de la configuración | 10 | Plan de gestión de configuración, registro de elementos de configuración, informe de estado, plan de líneas base, informe de auditoría de configuración, matriz de dependencias, plan de control de versiones, registro de liberaciones, documento de ambientes, plan de despliegue |
| Gestión de cambios | 10 | Plan de gestión de cambios, registro de solicitudes de cambio, informe de impacto, informe de cambios implementados, documento de reversión |
| Cumplimiento y regulaciones | 12 | Incluye el informe de auditoría interna de cumplimiento |
Fuente: catálogo de documentos técnicos de la plataforma, verificado en código, secciones 06, 07, 09 y 11 · 27 de septiembre de 2026
Ese expediente es la diferencia entre decir «el sistema es seguro» y poner sobre la mesa la matriz de controles, el registro de versiones y el informe de auditoría de configuración del sistema que usted usa. El auditor no discute adjetivos: pide documentos con fecha.
Cuando el expediente del sistema existe, la auditoría deja de ser un proyecto y pasa a ser una consulta.
Lo que esta página no afirma
Cuatro cosas se dejan dichas para que nadie las lea de más, porque en esta capa la credibilidad se gasta una sola vez y en salud se gasta más rápido.
Vantus Medical le permite demostrar cumplimiento. La responsabilidad de cumplir sigue siendo del establecimiento, y así lo dicen las propias normas: el expediente es del establecimiento y el establecimiento responde por él.
- No existe una certificación oficial mexicana de expediente clínico electrónico. Lo que existe es la conformidad con la NOM-024-SSA3-2012, que se declara y se acredita ante la autoridad sanitaria; no hay un sello que un programa pueda exhibir.
- El Consejo de Salubridad General certifica establecimientos, no programas. El sistema sostiene la evidencia documental y de indicadores que el modelo de certificación pide; la certificación la obtiene su hospital, a su nombre.
- La normativa estadounidense de salud no aplica a un establecimiento mexicano que no trata información de salud protegida de aquel país. No se vende como requisito.
- No se publica ninguna cifra de tiempo del sistema que no esté medida. Las cifras de latencia que circulan en el material técnico interno son estimaciones sin instrumentación, y por eso no aparecen en esta página ni en ninguna otra.
Preguntas frecuentes
¿Quién es hoy la autoridad de protección de datos personales en México?
La Secretaría Anticorrupción y Buen Gobierno. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente se publicó en el Diario Oficial de la Federación el 20 de marzo de 2025, entró en vigor el 21 de marzo de 2025 y fue reformada el 14 de noviembre de 2025; sustituye a la ley de 2010 y traslada la competencia, que ya no corresponde al Instituto Nacional de Transparencia. Si su aviso de privacidad lo menciona como autoridad, hay que corregirlo.
¿Queda registro de quién abrió un expediente, no sólo de quién lo cambió?
Sí, y son dos registros distintos. El cambio de estado deja historial de la entidad con estado anterior y estado nuevo, y bitácora con valor anterior y valor nuevo. El acceso está declarado en el modelo de datos del proyecto del expediente clínico del motor, en una entidad de bitácora cuyo propósito nombra expresamente los accesos a expedientes, y tiene además un caso de uso propio de auditoría de acceso con su actor responsable.
¿Cuánto tiempo hay que conservar el expediente clínico?
La NOM-004-SSA3-2012 fija un plazo mínimo de cinco años contados a partir del último acto médico, y deja el expediente bajo resguardo del establecimiento. El brochure del sistema tabula un rango de cinco a diez años según el acto, porque hay actos cuya exposición médico-legal vive más que el mínimo. El umbral por encima del piso legal lo fija su establecimiento; el sistema lo parametriza.
¿El sistema hace el respaldo de mi base de datos?
No como política corporativa. Cada cambio aplicado sobre el sistema en operación incluye un respaldo del artefacto que se toca y una instantánea de versión con su número, lo que permite reconstruir cómo estaba una pantalla en una fecha dada. La política de respaldo de la base, la prueba de restauración, el plan de recuperación y la custodia de las llaves de cifrado son del establecimiento. El sistema entrega los documentos que esos planes necesitan como parte del expediente técnico.
¿Puede un médico saltarse el permiso en una urgencia?
Ese es el caso que hay que resolver bien, porque negar el acceso en una urgencia también hace daño. El acceso de emergencia no se prohíbe: se concede, se registra con su justificación y queda marcado para revisión posterior. El mecanismo es de la plataforma; la revisión de cada uso y la consecuencia cuando no procedía son del establecimiento.
¿Con esto ya cumplo con la protección de datos?
No, y decirlo es parte de la respuesta. El sistema le da los controles y la evidencia: permiso por rol, bitácora de acceso y de cambio, registro del aviso de privacidad aceptado y del consentimiento, política de cifrado, registro de incidentes y el expediente documental. Redactar el aviso, mantenerlo vigente, recabar el consentimiento expreso y por escrito, atender los derechos de los titulares y notificar una vulneración son obligaciones del establecimiento, y ninguna se delega a un programa.
Referencias
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Publicada en el Diario Oficial de la Federación el 20 de marzo de 2025, en vigor desde el 21 de marzo de 2025; reforma del 14 de noviembre de 2025. Sustituye a la ley de 2010 y traslada la competencia a la Secretaría Anticorrupción y Buen Gobierno. Consultada el 27 de septiembre de 2026. ↗
- NOM-004-SSA3-2012, Del expediente clínico. Secretaría de Salud. Publicada en el Diario Oficial de la Federación el 15 de octubre de 2012; abroga la NOM-168-SSA1-1998. Contenido y organización mínimos del expediente y de cada nota, y su conservación. Consultada el 27 de septiembre de 2026. ↗
- NOM-024-SSA3-2012, Sistemas de información de registro electrónico para la salud. Intercambio de información en salud. Secretaría de Salud, Dirección General de Información en Salud. Publicada en el Diario Oficial de la Federación el 30 de noviembre de 2012. Integridad, autenticidad, confidencialidad, disponibilidad y trazabilidad. Consultada el 27 de septiembre de 2026. ↗
- Consejo de Salubridad General · Modelo de certificación y estandarización de buenas prácticas en atención de servicios de salud, manual para hospitales, segunda edición. Manual aprobado el 5 de marzo de 2026; recepción de solicitudes de certificación desde el 6 de abril de 2026. Consultado el 27 de septiembre de 2026. ↗
- Motor del motor de la casa · base del motor de la casa: modelo de datos de los otros proyectos del dominio de salud (entidades log_auditoria, nota_clinica, permiso, usuario_rol y caso de uso de auditoría de acceso a registros clínicos), el cuarto del dominio (entidades auditoria, historial_cita e historial_paciente) y el tercero (entidades access_logs, incidentes_seguridad, avisos_privacidad_aceptados, consentimientos_legales, politicas_cifrado y credentials). Leído el 27 de septiembre de 2026, hora del propio servidor.
- Evidencia de plataforma: dossier técnico del motor de la casa, archivos, con cita de archivo y línea en el expediente interno sobre código en disco. Verificado el 27 de septiembre de 2026.
El modelo
Primero ve su sistema funcionando, sin costo y sin compromiso. Después decide si lo compra o lo renta.
No es un demo: es Vantus Medical con sus procesos, sus áreas y su operación dentro. Entra, lo recorre y lo usa. Verlo no cuesta nada y no lo compromete a nada. Cuando decida, cobramos por resultados, no por entregables.