Vantus Medical · los cambios
El cambio no es un proyecto. Es un estado del sistema, con su registro.
La aseguradora cambió su tabulador, el consejo abrió un piso nuevo y la autoridad publicó una ley de datos personales con otra autoridad dentro. En el modelo con el que se le vendió, cada una de esas tres cosas es una orden de cambio. Aquí es una edición con su bitácora.
Por qué existe la orden de cambio, y de qué es síntoma
La orden de cambio no es un trámite administrativo: es la consecuencia lógica de un modelo de contratación. Cuando el sistema que usted usa se le licenció cerrado, cualquier diferencia entre su operación y el producto se vuelve trabajo de alguien que no es usted. Ese trabajo hay que cotizarlo, aprobarlo, calendarizarlo, probarlo y facturarlo. La orden de cambio es la factura de esa distancia.
El efecto secundario es más caro que la factura. Con el tiempo, su hospital aprende a no pedir. Se deja de capturar el dato que la aseguradora pediría, la auditoría de cuentas arma su control en una hoja de cálculo paralela, enfermería vuelve al formato impreso porque el campo que necesita no está, y el sistema que costó una fortuna termina sirviendo para facturar y para nada más. Y no es culpa de su gente: es el modelo con el que se le vendió.
En salud ese modelo choca con un hecho estructural: el hospital opera contra terceros que cambian sus reglas sin consultarlo. El tabulador de un convenio se mueve en una fecha. El portal de un pagador cambia el formato del envío. La autoridad publica una ley nueva de datos personales. El modelo de certificación saca edición nueva. Un sistema que cobra por cambiar es un sistema que se queda atrás de la operación que debía sostener.
Cuando pedir un cambio cuesta, el sistema deja de reflejar la operación. Y entonces el que decide vuelve a decidir con la hoja de cálculo.
El pretexto no es tecnológico
Lo que cambia en un hospital, en un año cualquiera
Antes de hablar del motor, conviene ver la lista de cambios reales que un hospital privado mexicano absorbió en los últimos ejercicios. Ninguno es una idea de mejora: casi todos son obligaciones con fecha, o decisiones de un tercero, que alguien tuvo que meter a un sistema.
Cambios con fecha que su sistema tuvo que absorber
| Cambio | Fecha | Qué toca dentro del sistema |
|---|---|---|
| Ley Federal de Protección de Datos Personales en Posesión de los Particulares: ley nueva y autoridad nueva | 20 de marzo de 2025, en vigor el 21 de marzo de 2025 | Texto del aviso de privacidad, registro del consentimiento, referencia a la autoridad ante la que se ejercen los derechos |
| Reforma a la misma ley | 14 de noviembre de 2025 | Revisión del aviso vigente y de la versión registrada como aceptada |
| Modelo de certificació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; solicitudes desde el 6 de abril de 2026 | Estándares acreditables, evidencia por estándar y expediente documental permanente de calidad |
| Clasificación internacional de enfermedades: entrada en vigor internacional de la undécima revisión | 1 de enero de 2022 (México sigue codificando con la décima) | Catálogo de codificación, mapeo y reportes a la autoridad sanitaria |
| Estándar de interoperabilidad de recursos de salud: publicación de la quinta versión | 26 de marzo de 2023 (la cuarta, del 27 de diciembre de 2018, es la que tiene contenido normativo y la más implantada) | Perfiles de intercambio, puntos de conexión y mapeo de recursos |
| Tabulador de un convenio con un tercero pagador | La fecha que fija el pagador, sin negociación técnica | Precios por convenio y plan, motor de honorarios, reglas de auditoría de cuenta y umbral de glosa probable |
| Layout de envío o de pago de un portal de aseguradora | La fecha que fija el pagador | Precarga al portal, anexo, contra recibo y conciliación del pago |
| Apertura de un servicio nuevo: piso, quirófano, unidad de cuidados intensivos o unidad de hemodiálisis | La fecha que decide su consejo | Sedes, camas, salas, catálogo de servicios, perfiles y reglas de asignación |
Fuente: Diario Oficial de la Federación (ley de protección de datos personales, 20 de marzo de 2025 y reforma del 14 de noviembre de 2025); Consejo de Salubridad General (manual para hospitales, segunda edición); Organización Mundial de la Salud (undécima revisión de la clasificación de enfermedades); historial de versiones del estándar de interoperabilidad; brochures Pack M y Pack G de Vantus Medical · verificado al 27 de septiembre de 2026
Ocho cambios obligatorios o impuestos por un tercero. En un modelo de órdenes de cambio, eso son ocho cotizaciones.
Los cuatro niveles de impacto, decididos antes de que usted edite
El motor de cambios de la plataforma no pregunta después qué tan grave fue lo que usted tocó. Lo sabe antes. Cada campo editable del sistema está clasificado en una tabla de reglas que vive en el código, y la clasificación se resuelve en tiempo de compilación, sin inferencia al momento.
Son 662 reglas de clasificación, contadas en el código: 2 en nivel bloqueado, 199 en nivel directo, 315 en nivel con efecto en cascada y 146 en nivel con aprobación. Un campo sin regla explícita cae al nivel directo por omisión, no a un limbo.
Nivel de impacto · qué hace el sistema
| Nivel | Nombre | Qué ocurre cuando alguien lo edita | Reglas |
|---|---|---|---|
| 0 | Bloqueado | El campo está deshabilitado en pantalla y no genera solicitud. Es el caso de lo que no se toca sin rehacer el expediente | 2 |
| 1 | Directo | Se aprueba solo y el cambio se aplica. Queda solicitud registrada y aplicada, sin tarea posterior | 199 |
| 2 | Directo con efecto en cascada | Se aplica de inmediato y encola la tarea que propaga el efecto al resto del sistema | 315 |
| 3 | Con aprobación | La solicitud queda pendiente y el campo se bloquea con un indicador en pantalla hasta que el responsable aprueba o rechaza | 146 |
Fuente: niveles declarados; conteo por nivel verificado · 27 de septiembre de 2026
Las tres reglas que gobiernan el comportamiento están escritas y son verificables. Bloqueo visual: si un campo tiene una solicitud pendiente, el control queda deshabilitado y muestra el indicador de espera, de modo que dos personas no pidan lo contrario sobre el mismo dato. Detección automática: el nivel de impacto se determina en compilación. Reversión incorporada: la escritura sobre la tabla de origen lleva el valor original, y es el motor el que aplica el valor nuevo cuando corresponde — por eso un cambio pendiente no deja el expediente a medias.
En un hospital ese último renglón importa más que en ninguna otra industria. Un cambio a medio aplicar sobre un catálogo de medicamentos o sobre un tabulador no es un inconveniente administrativo: es una prescripción con la dosis vieja o una cuenta enviada con el precio anterior.
Los tipos de cambio: quién lo pide, qué hace el sistema, qué registro queda
Esta es la tabla que sostiene la afirmación de la portada. Cada fila es un tipo de cambio que el sistema trata de manera distinta, con la tarea del motor que lo ejecuta cuando hay efecto en cascada y el registro que queda al terminar. Los ejemplos son de su operación, no de un manual.
Tipo de cambio · quién lo pide · qué hace el sistema · qué registro queda
| Tipo de cambio | Ejemplo en su hospital | Quién lo pide | Qué hace el sistema | Qué registro queda |
|---|---|---|---|---|
| Dato de configuración de nivel directo | El precio de un servicio en el catálogo; el umbral de aviso antes de una caducidad de insumo | El responsable del proceso, en su propia pantalla | Clasifica, aprueba solo y aplica el valor | Solicitud registrada y marcada como aplicada, con usuario y hora |
| Cambio de configuración con propagación | El tabulador de un convenio que la aseguradora movió; la lista de servicios que una sede nueva ofrece | El responsable del proceso | Aplica el valor y encola la tarea de configuración incremental, que ajusta el proyecto sin regenerarlo | Solicitud aplicada, tarea de cambio encolada y notificación informativa al proyecto |
| Alta de un artefacto nuevo | Una pantalla para la unidad de hemodiálisis que el hospital abre; una entidad para el registro que un pagador empezó a exigir | El responsable del proceso, con la aprobación del responsable del sistema | Inserta el artefacto —pantalla, entidad o relación— en el proyecto existente | Solicitud, artefacto dado de alta con su identificador y notificación |
| Renombrado con propagación | El rol «auditoría de cuentas» pasa a llamarse como lo llama su hospital | El responsable del sistema | Propaga el nombre nuevo a todos los textos del proyecto que lo referencian, sin intervención de un modelo de lenguaje | Solicitud aplicada y registro de los campos alcanzados |
| Baja en cascada | Se retira un convenio vencido o un perfil que dejó de existir en la organización | El responsable del sistema | Elimina en cascada el artefacto aprobado y lo que dependía de él | Solicitud aplicada y notificación informativa |
| Cambio con aprobación | El umbral con el que el auditor de cuenta marca una partida fuera de tabulador; el criterio con el que se cierra un expediente al alta | Lo pide quien opera; lo aprueba quien responde por el proceso | Deja la solicitud pendiente y bloquea el campo en pantalla hasta la decisión | Solicitud con comentario obligatorio del aprobador, y su estado: aprobada o rechazada |
| Cambio bloqueado | La llave del expediente de un episodio ya cerrado y facturado | Nadie: el campo no es editable | El control está deshabilitado en pantalla y no genera solicitud | No hay cambio, y por eso no hay duda sobre el expediente |
| Cambio con efecto en el código | Una pantalla que cambia de campos porque el pagador pide un dato más en el expediente del siniestro | El responsable del proceso | Ejecuta comprobación previa, respaldo, el cambio y el posproceso; y donde toca, regenera la capa de datos, los servicios y la pantalla | Instantánea de versión de la pantalla, con número de versión consultable |
Fuente: tareas de gestión de cambios del motor y recorrido completo de un cambio:539-586 · los ejemplos de operación provienen de los brochures Pack M y Pack G de Vantus Medical · 27 de septiembre de 2026
Ocho tipos de cambio, ocho registros distintos. Ninguno de los ocho se cotiza.
Qué pasa, paso por paso, cuando alguien cambia algo
El recorrido está documentado y es el mismo para todos los niveles; lo que cambia es dónde se detiene. Se describe lo que ocurre, en orden, sin decir cuánto tarda.
Nadie abrió un ticket. Nadie cotizó. Y aun así hay expediente: solicitud, decisión, comentario, respaldo, versión y notificación.
- La pantalla pregunta antes de dibujarse. Al abrir, consulta qué campos tienen solicitud pendiente y los deshabilita con su indicador.
- Al guardar, el cambio se intercepta. La operación registra el cambio como tal, y la escritura sobre la tabla de origen lleva el valor original.
- El motor clasifica. Devuelve nivel de impacto, tarea de cambio asociada y tipo de operación.
- Se crea la solicitud. Auto-aprobada en los niveles directos, pendiente en el nivel con aprobación.
- Se decide. En los niveles directos, el propio sistema. En el nivel con aprobación, el responsable desde la pantalla de gestión de cambios, que aprueba o rechaza.
- El procedimiento aplica el cambio. Lee la solicitud, escribe sobre la tabla correspondiente, pasa la solicitud a aprobada, si el cambio tiene efecto en cascada, encola la tarea que lo propaga.
- Se ejecutan los efectos. Comprobación previa, respaldo, cambio, posproceso y —cuando el cambio lo exige— regeneración de la base, de los servicios y de las pantallas afectadas.
- Queda la versión. Se calcula el número de versión nuevo y se guarda la instantánea, consultable después por pantalla.
La matriz de estados de una solicitud de cambio
Una solicitud de cambio es una entidad con estados, no un correo. El catálogo de estados está en la plataforma de la casa y tiene ocho entradas, transcritas aquí tal como están.
Un detalle que conviene decir porque circula al contrario: no existe un estado «revertido» en el catálogo del motor. Aparece mencionado en material interno de trabajo y no está en la base. La reversión se sostiene con el respaldo del artefacto y la instantánea de versión —que sí existen y se citan más arriba— y con una tabla propia de solicitudes de reversión que guarda, por cada una, la tabla objetivo, la columna llave, el número de filas, la operación y los datos capturados antes de tocar nada.
Los ocho estados de una solicitud de cambio, transcritos del motor
| # | Estado | Qué significa en la práctica |
|---|---|---|
| 1 | Por analizar | La solicitud existe y espera clasificación |
| 2 | Analizando | El motor está resolviendo nivel de impacto y efectos |
| 3 | Por aprobar | Espera la decisión del responsable; el campo está bloqueado en pantalla |
| 4 | Aprobada | La decisión está tomada y el cambio va a escribirse |
| 5 | Rechazada | La decisión fue no, con su comentario |
| 6 | Por aplicar cambios | Aprobada y en cola de aplicación |
| 7 | En proceso de aplicación de cambios | Hay una tarea de propagación corriendo |
| 8 | Cambios aplicados | El cambio está en el sistema, con su instantánea de versión |
Transcrito del motor de la casa, tabla cat_estado_cambio, consultada el 27 de septiembre de 2026, hora del propio servidor. El recorrido documentado del caso frecuente es 1 → 3 → 4 → 7 → 8, con 5 como salida de la decisión.
Ese catálogo no es una declaración de intenciones: tiene uso. Al mismo corte, la base del motor guarda 339 solicitudes de cambio repartidas sobre 68 proyectos, con 270 registros de impacto asociados y 64 solicitudes de reversión con sus datos capturados. El reparto por estado dice que 158 están aplicadas, 119 en proceso de aplicación, 18 aprobadas, 15 rechazadas, 6 por aprobar y 23 por analizar. El reparto por nivel dice que 114 son de nivel directo, 143 de nivel con efecto en cascada y 55 de nivel con aprobación.
Qué se verificó, con su fecha
La afirmación «los cambios se hacen en la sesión» sólo vale si alguien la probó campo por campo. La verificación de cobertura del motor de cambios existe, está fechada y dice lo siguiente.
Verificación de cobertura del motor de cambios
| Qué se verificó | Resultado | Fecha y origen |
|---|---|---|
| Campos editables recorridos de extremo a extremo | 229 campos en 63 entidades, con cero errores | 31 de mayo de 2026 |
| Reparto de esos campos por comportamiento | 175 se aprueban solos · 52 quedan pendientes de aprobación · 2 están bloqueados | 31 de mayo de 2026 |
| Corrida anterior, para comparar | 174 campos, cero errores | 30 de mayo de 2026 |
| Reglas de clasificación en el código | 662 reglas: 2 bloqueadas, 199 directas, 315 con cascada, 146 con aprobación | Conteo en código |
| Solicitudes de cambio vivas en la base del motor | 339 solicitudes sobre 68 proyectos, 270 registros de impacto y 64 solicitudes de reversión con datos capturados | Plataforma de la casa · 27 de septiembre de 2026, hora del servidor |
| Pantallas del portal con el motor integrado y pantallas sin él | Inventario con sus huecos nombrados: dos pantallas con regla declarada y sin integración de pantalla, y 31 pantallas fuera del motor por diseño | Verificación interna de cobertura |
Fuente: verificación interna de cobertura del motor de cambios de la plataforma, con las fechas indicadas, y conteo sobre la base del motor
Se publica también el hueco, porque un inventario que sólo lista lo que funciona no es un inventario. Hay pantallas del portal cuya regla de clasificación existe en el código sin la integración correspondiente en la pantalla, y hay pantallas que quedan fuera del motor por decisión de diseño. Están nombradas una por una en el inventario interno, con su fecha.
229 campos probados, cero errores, y los huecos con nombre. Eso es una verificación; lo demás es una promesa.
Por qué no hay orden de cambio
La respuesta no es comercial, es estructural. La orden de cambio existe para resolver cuatro incógnitas: qué tan grave es el cambio, quién tiene que autorizarlo, qué más se rompe y cuánto cuesta el trabajo de aplicarlo. En este sistema las cuatro están resueltas antes de que usted abra la pantalla.
Lo único que queda del ciclo tradicional es la parte que sí es suya: la decisión clínica o administrativa sobre si el cambio debe hacerse.
- La gravedad no se estima: está clasificada. 662 reglas en el código dicen el nivel de impacto de cada campo, decidido en compilación. No hay una junta que lo dictamine.
- La autorización no es un comité: es un estado. Los 146 campos de nivel con aprobación la piden dentro del sistema, a quien responde por el proceso, con comentario obligatorio. Los otros no la necesitan porque su efecto ya está acotado.
- Lo que se rompe no se investiga: se propaga. Las tareas de configuración incremental, alta de artefacto, renombrado con propagación y baja en cascada existen precisamente para eso, y son parte del motor, no de un proyecto aparte.
- El trabajo de aplicarlo no se cotiza porque no se hace a mano. Donde el cambio toca el código, el propio motor regenera la capa de datos, los servicios y la pantalla, y guarda la versión. No hay horas de consultoría que facturar porque no hay horas de consultoría.
Dicho al revés, que es como se entiende mejor: no es que hayamos decidido no cobrar por los cambios. Es que el cambio dejó de ser un entregable. Y cuando el cambio no es un entregable, no hay nada que facturar por entregarlo — por eso el trato es cobrar por resultados.
El contraste, en términos del modelo de contratación
La comparación que sigue no habla de la calidad de ningún producto ajeno. Habla del modelo con el que se contrata, que es lo que determina qué le pasa a usted el día que una aseguradora mueve su tabulador o la autoridad publica una ley nueva.
El mismo cambio, dos modelos de contratación
| Cuando cambia una regla de su operación | En un sistema licenciado, con órdenes de cambio | En Vantus Medical |
|---|---|---|
| Quién decide si se puede hacer | El proveedor, tras un análisis de viabilidad que se contrata | Está decidido: el campo tiene su nivel de impacto en el código |
| Quién autoriza | Un comité de control de cambios, con acta | El responsable del proceso, dentro del sistema, con comentario obligatorio |
| Qué se firma antes de empezar | Cotización, alcance y calendario | Nada. La solicitud es el registro, y la genera el propio sistema |
| Quién ejecuta | Consultoría, propia o de un socio implementador | El motor, con sus tareas de propagación y regeneración |
| Qué pasa con los demás módulos | Se investiga el impacto y se cotiza aparte | La propagación es parte del tipo de cambio: renombrado, alta, baja en cascada |
| Cómo se prueba | Un ciclo de pruebas contratado | Comprobación previa y posproceso dentro del recorrido; el sistema deja la versión |
| Qué queda documentado | El acta del comité y la orden firmada | Solicitud, estado, comentario, respaldo, instantánea de versión y notificación |
| Qué pasa si sale mal | Una orden de cambio nueva | El respaldo del artefacto y la instantánea de versión anterior existen desde antes de aplicar, y la solicitud de reversión guarda los datos capturados |
| Qué aprende su hospital | A no pedir | A pedir, porque pedir no cuesta |
Comparación sobre el modelo de contratación, no sobre la calidad de ningún producto ajeno · 27 de septiembre de 2026
El que cobra por cada cambio tiene un incentivo que usted no comparte: que su operación no se parezca al producto.
Lo que esta página no le promete
Aquí no aparece ningún número de días, de horas ni de milisegundos, y la razón se dice completa: en el material técnico de la plataforma existen cifras de latencia del motor de cambios, y al revisarlas resultaron ser estimaciones escritas en un diagrama, sin instrumentación, sin entorno de medición, sin percentil y sin fecha. Una cifra así no se publica, aunque favorezca.
Tampoco se publica un porcentaje de cobertura que circula en el mismo material, porque su aritmética no cuadra con el universo de campos verificado: el porcentaje corresponde a una corrida anterior, con menos campos, y se le pegó la etiqueta de la corrida grande. Lo que sí se publica es lo que se contó: 662 reglas en el código, 229 campos recorridos con cero errores el 31 de mayo de 2026, y el reparto entre los que se aprueban solos, los que esperan aprobación y los que están bloqueados.
Y queda una distinción que conviene no perder. «En la sesión» describe dónde ocurre el cambio —dentro del sistema, en la pantalla donde se trabaja, sin salir a un proceso paralelo—, no cuánto tarda el reloj. Lo que se compromete es que no hay una orden de cambio entre su decisión y el sistema. El resto lo verá usted mismo cuando lo tenga enfrente.
Se describe lo que ocurre. No se compromete un número de días.
Preguntas frecuentes
¿De verdad no hay órdenes de cambio, o es una forma de hablar?
No las hay porque el cambio no es un entregable que alguien tenga que producir a mano. Cada campo editable está clasificado en uno de cuatro niveles de impacto por una tabla de 662 reglas en el código; la autorización, cuando hace falta, es un estado de la solicitud dentro del propio sistema; y la propagación al resto del sistema la ejecuta el motor con sus tareas de configuración incremental, alta de artefacto, renombrado y baja en cascada.
¿Entonces cualquiera puede cambiar cualquier cosa del expediente?
No. Dos campos están en nivel bloqueado y no son editables por nadie; 146 exigen aprobación del responsable, con comentario obligatorio, y mientras esperan, el campo queda deshabilitado en pantalla con su indicador (regla de bloqueo visual). Y lo que la norma fija no es un parámetro: el contenido mínimo del expediente y de cada nota lo determina la NOM-004-SSA3-2012, no la configuración.
¿En cuánto tiempo queda aplicado un cambio?
No publicamos un plazo, y decimos por qué: las cifras de tiempo que existen en el material técnico interno son estimaciones escritas en un diagrama, sin instrumentación ni entorno de medición. Lo que sí está verificado es el recorrido —solicitud, clasificación, decisión, aplicación, propagación, versión— y que 229 campos se recorrieron de extremo a extremo con cero errores el 31 de mayo de 2026. El plazo lo comprobará usted en el sistema, no en esta página.
Si el cambio toca una pantalla, ¿alguien programa?
El motor regenera. Donde el cambio exige tocar la capa de datos, los servicios o la pantalla, el recorrido incluye comprobación previa, respaldo, el cambio, el posproceso y la regeneración de la base, de los servicios y de las pantallas afectadas, y termina guardando una instantánea de versión consultable.
¿Qué pasa si el cambio sale mal?
El respaldo del artefacto y la instantánea de versión se producen dentro del propio recorrido, antes y después de aplicar, no como un trámite aparte. Lo que no existe es un estado «revertido» de la solicitud: el catálogo de estados del motor tiene ocho entradas y ninguna es ésa (cat_estado_cambio, consultada el 27 de septiembre de 2026). La reversión se sostiene con el respaldo, con la versión y con una tabla propia de solicitudes de reversión que guarda tabla objetivo, columna llave, número de filas, operación y datos capturados; al corte tiene 64 registros.
¿Cuándo sí tengo que hablar con alguien de la casa?
Cuando el cambio no es de configuración sino de criterio: un proceso clínico que su hospital decide operar distinto, una línea de servicio que abre por primera vez, un tercero pagador con un esquema de dictaminación que nunca había entrado. Esa conversación es sobre la operación y no se factura como orden de cambio: el trato es cobrar por resultados, no por entregables.
Referencias
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Diario Oficial de la Federación, 20 de marzo de 2025, en vigor el 21 de marzo de 2025; reforma del 14 de noviembre de 2025. 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 desde el 6 de abril de 2026. Consultado el 27 de septiembre de 2026. ↗
- NOM-004-SSA3-2012, Del expediente clínico. Secretaría de Salud. Diario Oficial de la Federación, 15 de octubre de 2012. Contenido mínimo del expediente y de cada nota: lo que no es parametrizable. Consultada el 27 de septiembre de 2026. ↗
- HL7 International · historial de versiones del estándar de interoperabilidad de recursos de salud: la cuarta versión (4.0.1) del 27 de diciembre de 2018 es la que contiene el primer contenido normativo; la quinta (5.0.0) se publicó el 26 de marzo de 2023. Consultado el 27 de septiembre de 2026. ↗
- Motor del motor de la casa · base del motor de la casa: tabla cat_estado_cambio (ocho estados, sin estado «revertido»), solicitud_de_cambio (339 filas sobre 68 proyectos, con su reparto por estado y por nivel), solicitud_de_cambio_impacto (270 filas) y cm_solicitud_reversion (64 filas con tabla objetivo, columna llave, número de filas, operación y datos capturados). Consultadas el 27 de septiembre de 2026, hora del propio servidor.
- Evidencia de plataforma: motor de cambios del motor de la casa — 662 reglas de clasificación y su reparto por nivel; niveles de impacto, recorrido y estados de la solicitud; verificación de cobertura, 30 y 31 de mayo de 2026; y inventario y huecos. Recogidas con cita de archivo y línea en el expediente interno. 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.