Cuando un comité de decisión de una obra social, prepaga o mutual llega a la instancia de evaluar proveedores de software, ya pasó por lo más difícil: reconocer que el sistema actual tiene un límite y que el cambio es necesario. Lo que sigue debería ser más simple — comparar opciones y elegir la mejor. En la práctica, no lo es.
El problema es que en las demos casi todos son buenos. La mayoría de los proveedores muestra su sistema en el mejor escenario posible: datos limpios, flujos optimizados, casos de éxito seleccionados. La diferencia real entre una plataforma y otra no aparece en la demo — aparece en las preguntas que el comité sabe hacer, y en las respuestas que el proveedor da o evita dar.
Esta guía está diseñada para ese momento. No es una lista de características técnicas a verificar: es un conjunto de preguntas que apuntan exactamente a los puntos donde los proyectos de software sanitario fallan, se demoran o decepcionan. Cada una tiene una lógica. Cada respuesta dice algo sobre el proveedor.
Por qué las 12 preguntas — y no una lista de funcionalidades
Evaluar software por funcionalidades es necesario pero insuficiente. Casi todas las plataformas del mercado cumplen los requisitos básicos de gestión de afiliados, liquidación y autorizaciones. La diferencia no está en qué hacen — está en cómo lo hacen, cuánto tardaron en implementarlo, qué pasó cuando algo falló, y qué tan dependiente quedó el cliente del proveedor después del inicio de la relación comercial.
Las preguntas que siguen no buscan que el proveedor diga que sí — buscan entender cómo trabaja, con qué clientes, bajo qué condiciones y con qué compromisos reales. Un proveedor que evita responderlas, o las responde en términos genéricos, ya te contestó la pregunta más importante: cómo va a manejar los problemas una vez iniciada la relación contractual.
Las 12 preguntas
Pregunta 1: ¿Cuántos financiadores de salud tienen el sistema implementado y en producción hoy?
Por qué importa: La experiencia se mide en dos planos: la trayectoria en el mercado —años de exposición a distintos marcos regulatorios y escenarios operativos— y la evidencia de que el sistema funciona hoy, en producción, de forma estable. Hay riesgos tanto en un proveedor que puede tener muchos años sin haber gestionado nunca la complejidad de un financiador grande, o en otro que puede mostrar clientes nuevos sin trayectoria que respalden su capacidad de sostenerlos en el tiempo.
Tampoco alcanza con mirar la cantidad de clientes activos hoy: lo que importa es el volumen que administra —afiliados, transacciones— y la variedad de escenarios que enfrentó a lo largo de su trayectoria, desde organizaciones grandes hasta otras más chicas que requieren mayor personalización.
Qué buscar: Antigüedad del proveedor en el sector y años de trayectoria con el producto en producción. Referencias concretas y verificables —no un logo, sino un cliente con nombre, tamaño de padrón y tiempo real de operación con el sistema—. Volumen administrado: cantidad de afiliados y transacciones procesadas de forma estable. Diversidad de escenarios atendidos a lo largo del tiempo: organizaciones de distinto tamaño y complejidad operativa, no solo la cartera de clientes actual.
Pregunta concreta al proveedor: “¿Podemos hablar con dos o tres clientes actuales de tamaño similar al nuestro?”
Pregunta 2: ¿Cómo es el proceso de migración de datos históricos?
La migración es el momento de mayor riesgo en cualquier cambio de sistema. Si el proveedor no tiene un proceso documentado para migrar históricos de prestaciones, padrones y contratos con prestadores, ese riesgo recae íntegramente en el cliente.
Qué buscar: Un proceso por fases con validación cruzada entre sistema origen y destino, sin downtime de operación y con validación conjunta entre el proveedor y el equipo técnico del cliente al cierre de cada fase — no una certificación unilateral del proveedor sobre sus propios datos.
Pregunta concreta al proveedor: “¿Quién es responsable de los lineamientos de la migración — su equipo o el nuestro? ¿Qué pasa si los datos migrados presentan inconsistencias?”
Pregunta 3: ¿Cuánto tiempo tarda una implementación estándar y qué factores la extienden?
Los plazos de implementación son el área de mayor discrepancia entre lo que se promete y lo que ocurre. Preguntar cuánto tarda no alcanza — hay que entender qué variables lo extienden y quién asume el costo de esa extensión.
Qué buscar: Un plazo con hitos definidos, criterios claros de avance y una metodología que no dependa del equipo IT del cliente para cada decisión técnica.
Pregunta concreta al proveedor: “¿Cuál fue el promedio real de sus últimas implementaciones? ¿Qué los extendió?”
Pregunta 4: ¿Cómo funciona el soporte después de la implementación?
El soporte post-implementación es donde la relación comercial muestra su cara real. Muchos proveedores tienen SLAs en el contrato que en la práctica se traducen en tickets, demoras y respuestas genéricas. El financiador que depende de su sistema para operar no puede permitirse ese modelo.
Qué buscar: SLA con tiempos de respuesta diferenciados por criticidad, canal de escalamiento definido y responsable de cuenta con conocimiento del sistema del cliente —no un esquema donde cada consulta empieza de cero con alguien distinto.
Pregunta concreta al proveedor: “¿Cuánto tarda en promedio la resolución de un incidente crítico en producción? ¿Quién es el contacto directo cuando el sistema está caído?”
Pregunta 5: ¿Cómo se actualizan los requisitos regulatorios (PMO, receta electrónica, normativas de la SSS)?
El sistema de salud argentino cambia con frecuencia: nuevas normativas de la Superintendencia de Servicios de Salud, cambios en el PMO, nuevos requisitos de trazabilidad. El financiador que usa un sistema que no se adapta en tiempo y forma asume el riesgo regulatorio por cuenta propia.
Qué buscar: Actualizaciones regulatorias incluidas como parte del servicio (sin costo adicional), con plazo comprometido desde la publicación oficial de la normativa.
Pregunta concreta al proveedor: “¿Cuánto tardaron en implementar la Resolución 1725/25 para sus clientes actuales?”
Pregunta 6: ¿Qué nivel de disponibilidad y visibilidad en tiempo real ofrece sobre el gasto prestacional?
Un sistema que solo registra transacciones y genera reportes ad hoc no permite gestión financiera activa. La capacidad de ver el gasto prestacional en tiempo real — por práctica, prestador y zona — es la diferencia entre un sistema de registro y un sistema de gestión.
Qué buscar: Visibilidad en tiempo real del gasto comprometido y liquidado, con alertas configurables por desvío sobre parámetros definidos.
Pregunta concreta al proveedor: “¿Puedo saber hoy cuánto comprometí en autorizaciones este mes sin pedirle un reporte al área de IT?”
Pregunta 7: ¿Cómo se configuran los criterios que el sistema aplica para autorizar, rechazar o alertar?
Todo sistema de gestión sanitaria aplica criterios — de negocio y sanitarios — para decidir qué autorizar, qué rechazar y qué alertar. La pregunta no es si el sistema tiene esos criterios, sino quién los define y con qué grado de flexibilidad puede ajustar a un cambio de convenio, protocolo, normativa, etc.
Qué buscar: Un motor de reglas configurable por el propio equipo del financiador, capaz de aplicar criterios distintos según el tipo de transacción (prestaciones, medicamentos, eventos médicos), el actor interviniente y el contexto — con trazabilidad de cada decisión tomada.
Pregunta concreta al proveedor: “¿Quién define los criterios de evaluación día a día — nuestro equipo o el suyo? ¿Cuánto tarda en reflejarse un cambio de criterio una vez definido?”
Pregunta 8: ¿Qué pasa con nuestros datos si decidimos cambiar de proveedor en el futuro?
Esta pregunta incomoda a muchos proveedores — y por eso es obligatoria. Un proveedor que no puede garantizar la portabilidad de los datos en formato estándar ante una eventual migración futura está creando una dependencia que no está en el contrato pero sí en la operación.
Qué buscar: Compromiso explícito de exportación de datos en formato estándar (JSON, CSV, XML) sin costo adicional y sin restricciones ante finalización del contrato.
Pregunta concreta al proveedor: “Si en tres años decidimos migrar a otro sistema, ¿qué formato tienen nuestros datos y quién nos ayuda a exportarlos?”
Pregunta 9: ¿Cómo integra el sistema con los canales digitales del afiliado (app, portal, identidad digital)?
La desregulación del sistema de salud convirtió la experiencia digital del afiliado en un factor de retención. Un financiador con un sistema de gestión que no se integra con canales digitales no puede ofrecer una experiencia que compita con la ofrecida por prepagas del mercado.
Qué buscar: Integración nativa o documentada con módulos de identidad digital del afiliado, app móvil y portal de prestadores, con API abierta para integraciones futuras.
Pregunta concreta al proveedor: “¿Cómo se integra la identidad digital del afiliado con el core de gestión? ¿Puedo agregar canales digitales nuevos sin reemplazar el sistema?”
Pregunta 10: ¿Qué certificaciones tiene el sistema y cómo garantiza la seguridad de los datos de salud?
Los datos de salud son de las categorías más sensibles en cualquier marco regulatorio. Un proveedor sin certificaciones de calidad ni políticas documentadas de seguridad de la información no puede garantizar el nivel de protección que un financiador necesita — ni frente a sus afiliados ni frente a la regulación.
Qué buscar: Certificación ISO 9001 como mínimo, política de seguridad de la información documentada y accesible, y definición clara de dónde se alojan los datos y bajo qué condiciones.
Pregunta concreta al proveedor: “¿Tienen certificación ISO 9001 o equivalente? ¿Dónde están alojados nuestros datos y qué protocolos aplican ante un incidente de seguridad?”
Pregunta 11: ¿Qué nivel de trazabilidad ofrece el sistema sobre cada decisión tomada?
La trazabilidad no es un atributo técnico secundario — es lo que permite al financiador responder ante un requerimiento de la SSS, resolver una disputa con un prestador o afiliado, responder un requerimiento legal, o auditar un proceso interno sin depender de la memoria de las personas. Un sistema que no registra quién decidió qué, cuándo, o que pierde el historial ante cambios del afiliado (plan, rol, baja y reingreso, etc), deja al financiador expuesto cada vez que alguien realiza preguntas respecto de los servicios brindados a un afiliado, pactados y/o brindados por un prestador, etc..
Qué buscar: Registro de cada acción con el usuario que la realizó y el momento exacto. Que las excepciones y los controles que requirieron auditoría dejen registrado quién tomó la decisión y cuándo. Que todo sea consultable sin necesidad de generar un reporte ad hoc ni de intervención del área IT.
Pregunta concreta al proveedor: “Si en el contexto de un amparo nos piden justificar una prestación autorizada como excepción hace seis meses, ¿podemos ver quién la autorizó y cuándo, aunque el afiliado haya cambiado de plan desde entonces? ¿En cuánto tiempo y en qué formato nos entregan esa información?”
Pregunta 12: ¿Qué tan interoperable es la plataforma con sistemas externos?
Un sistema de gestión sanitaria no opera en soledad. Se conecta con prestadores, farmacias, carriers de transacciones, plataformas de identidad digital, sistemas administrativos (ERP, CRM), herramientas de explotación de datos, etc.. La pregunta no es si el sistema tiene integraciones hoy — es si su arquitectura permite incorporar nuevas sin depender de un desarrollo a medida cada vez.
Qué buscar: Protocolos estándares y APIs que permitan integraciones con terceros sin requerir intervención del proveedor para cada conexión nueva. Capacidad de intercambio de datos por distintos mecanismos (on line, carga batch, etc.) y herramientas de analítica externa. Historial de integraciones ya implementadas como evidencia de que la arquitectura lo soporta en producción, no solo en teoría.
Pregunta concreta al proveedor: “¿Tienen APIs documentadas disponibles para el equipo técnico del cliente? ¿Qué integraciones con sistemas externos tienen hoy en producción?”
Cómo usar esta guía en el proceso de selección
Estas 12 preguntas funcionan mejor como instrumento de evaluación comparativa: hacérselas a todos los proveedores en el mismo formato y registrar las respuestas. Las diferencias se hacen evidentes cuando se comparan en paralelo.
Las respuestas que hay que cuidar no son las que dicen que no — son las que evitan la pregunta. Un proveedor que responde “eso se define en la implementación”, “depende del caso” o “podemos conversarlo” a preguntas que deberían tener respuestas concretas está diciéndote que no tiene el proceso documentado. En software sanitario, eso es un riesgo operativo.
Las 12 preguntas cubren los 7 ejes donde los proyectos de software sanitario más frecuentemente fallan: experiencia sectorial real, gestión del cambio y migración, operación post-implementación, capacidad de gestión financiera, autonomía del cliente frente al proveedor, trazabilidad de las decisiones e interoperabilidad con sistemas externos.
Preguntas frecuentes sobre cómo elegir software sanitario
¿Qué criterios son más importantes al evaluar software sanitario para financiadores?
Más allá de las funcionalidades, los criterios más críticos son: experiencia comprobable en el sector (no logos — referencias verificables), proceso de migración documentado, soporte post-implementación con SLA real, capacidad de actualización regulatoria sin costo adicional, y visibilidad en tiempo real del gasto prestacional. Un sistema que falla en cualquiera de estos ejes genera problemas operativos que no se resuelven con una nueva funcionalidad.
¿Cuánto tiempo lleva implementar un software de gestión sanitaria?
Varía según el volumen del padrón, el estado de los datos históricos y la complejidad de la red de prestadores. En términos generales, una implementación modular en un financiador de tamaño mediano puede llevarse en fases de 3 a 6 meses con operación continua durante el proceso. Lo importante es pedirle al proveedor el promedio real de sus últimas implementaciones — no el plazo ideal de su propuesta comercial.
¿Cómo sé si un software sanitario va a cumplir con los requisitos regulatorios de la SSS?
La pregunta correcta no es si el sistema cumple hoy — es cómo se actualiza cuando cambian las normativas. El sistema de salud argentino tiene una dinámica regulatoria activa: DNU 70/2023, receta electrónica, cambios en el PMO, nuevos requisitos de trazabilidad. Un proveedor que incluye las actualizaciones regulatorias en el servicio sin costo adicional y con plazo comprometido desde la publicación oficial es el que reduce ese riesgo a cero para el financiador.
¿Qué es la portabilidad de datos en software sanitario y por qué importa?
La portabilidad de datos es la capacidad de exportar toda la información del sistema — padrones, históricos de prestaciones, contratos, autorizaciones — en formato estándar si el financiador decide cambiar de proveedor en el futuro. Importa porque muchos contratos de software no garantizan esta portabilidad o la condicionan a costos adicionales, lo que genera una dependencia que no estaba en el análisis inicial de la compra.
La pregunta detrás de todas las preguntas
Elegir software sanitario es, en el fondo, elegir un socio operativo para los próximos 10 o 15 años. Las 12 preguntas de esta guía no son tecnicismos — son el instrumento para entender si el proveedor que está del otro lado del demo tiene la experiencia, los procesos y los compromisos para ser ese socio. HMS lleva 25 años siendo ese socio para obras sociales, prepagas y mutuales argentinas. Estas son las preguntas que, después de años trabajando con financiadores de salud, sabemos que marcan la diferencia entre una implementación tranquila y una llena de sorpresas.
