Los capítulos 5 a 12 desarrollan cada componente en profundidad, con actividades para completar en equipo. Como referencia rápida, esta tabla anticipa el error más frecuente de cada componente y un ejemplo aplicado tomado de los casos de esta guía:

En salud abundan las ideas románticas: proyectos interesantes en teoría, técnicamente atractivos, incluso nobles en su intención. El problema es que nadie los pidió, nadie los está sufriendo con urgencia y nadie tiene presupuesto asignado para resolverlos. Un dolor real es otra cosa: existe hoy, tiene un costo medible y alguien lo padece activamente.

Cómo distinguirlos

Hay tres señales que separan un dolor real de una idea romántica. La primera es la existencia presente: el problema ocurre hoy, no en un escenario futuro. La segunda es el costo: se puede estimar cuánto tiempo, dinero o calidad se pierde por su causa. La tercera es la urgencia: alguien ya está gastando recursos en soluciones imperfectas, o pidiendo ayuda de forma explícita. Si las tres señales están presentes, hay un problema sobre el cual construir. Si falta alguna, todavía hay trabajo de campo por hacer.

Medir el costo del problema es lo que después permitirá hablar de valor (capítulo 9). Por eso conviene cuantificarlo desde el inicio: minutos por paciente, turnos perdidos por semana, reclamos por mes, ingresos que no se facturan. Un problema sin número es una opinión; un problema con número es el comienzo de un producto.

Este es el componente que la mayoría de los equipos técnicos pasa por alto. Se diseña para “el usuario” como si fuera una sola figura, cuando en realidad hay al menos cuatro roles en juego. El usuario no siempre es quien paga. El decisor no siempre es quien sufre el problema. Y el comprador puede ser una clínica, un hospital, un financiador, un ministerio, una universidad o un programa sanitario — cada uno con sus tiempos, sus reglas y sus prioridades.

Mapear estos roles temprano evita dos errores clásicos. El primero: construir algo que los usuarios aman pero que ningún decisor autoriza. El segundo: venderle a un decisor algo que los usuarios van a resistir. Un producto de IA en salud se adopta cuando los cuatro roles encuentran su respuesta — el usuario gana tiempo, el pagador ve retorno, el decisor reduce riesgo y el influenciador no encuentra motivos para frenarlo.

“Queremos hacer algo con IA” es la frase que más proyectos ha matado. La pregunta correcta no es qué puede hacer el modelo, sino qué tarea concreta del mundo real vamos a mejorar. Una buena definición de solución especifica cuatro cosas: qué automatiza (una tarea que hoy hace una persona), qué asiste (una decisión que sigue siendo humana pero mejor informada), qué prioriza (un orden más inteligente de casos o tareas) o qué predice (un evento que conviene anticipar).

Igual de importante es definir los límites. Toda solución de IA en salud necesita responder: ¿qué NO va a hacer? ¿Dónde interviene una persona, y con qué responsabilidad? Explicitar los límites no debilita la propuesta — la vuelve creíble frente a decisores, comités de ética y equipos clínicos. En salud, una IA sin límites declarados es una IA que no se adopta.

Sugerencia: escriban la solución mínima en una sola tarjeta y muéstrensela a un colega que no participe del proyecto. Si necesita más de 30 segundos de explicación adicional, todavía no es mínima.

Pensar el flujo significa responder cómo entra la solución en la jornada real del usuario. ¿En qué momento exacto aparece? ¿Con qué sistemas convive — historia clínica electrónica, agenda, WhatsApp, planillas? ¿Qué pasos elimina y, sobre todo, qué fricciones nuevas agrega? Cada clic adicional, cada pantalla nueva, cada contraseña extra es un argumento en contra de la adopción.

Hay una prueba simple: dibujen el flujo actual, paso a paso, tal como ocurre hoy. Después dibujen el flujo con la solución integrada. Si la segunda versión tiene más pasos que la primera, o le exige al usuario abandonar las herramientas que ya usa, el producto tiene un problema serio — aunque el modelo sea excelente. Los mejores productos de IA en salud se insertan donde el trabajo ya sucede: dentro del sistema de historia clínica, dentro de WhatsApp, dentro de la agenda que la institución ya conoce.

Checklist de flujo

Antes de avanzar al siguiente componente, el equipo debería poder marcar cada casilla de esta lista con una respuesta concreta:

• ¿Dónde empieza el flujo? El evento exacto que lo dispara (llega un paciente, entra un mensaje, se agenda un turno).
• ¿Dónde termina? El resultado final verificable (nota firmada, turno confirmado, pago registrado).
• ¿Quién interviene? Personas y roles que participan, aprueban o supervisan.
• ¿Qué sistema se usa hoy? Historia clínica, agenda, planillas, WhatsApp, papel.
• ¿La solución reemplaza, complementa o automatiza? Definirlo evita expectativas equivocadas.
• ¿Cuántos clics agrega o elimina? Contarlos literalmente, uno por uno.
• ¿Qué pasa si falla? El camino alternativo cuando la IA no responde o se equivoca.

El valor de un producto de IA en salud puede tomar varias formas, y conviene conocerlas todas porque cada pagador es sensible a una distinta: tiempo ahorrado por jornada o por proceso; costos evitados (horas de personal, reprocesos, multas, insumos); ingresos recuperados (turnos que no se pierden, prestaciones que sí se facturan); errores reducidos con costo real asociado; y calidad o acceso mejorados — que en el sector público y en programas sanitarios son el valor central, y también se pueden medir: tiempos de espera, cobertura, oportunidad del diagnóstico, equidad territorial.

La fórmula se lee así: un valor convincente parte de un dolor que importa (capítulo 5), demuestra una mejora que se puede medir antes y después, y se apoya en evidencia de que alguien realmente lo usa (capítulo 12). Cuando falta alguno de los tres términos, el argumento se cae: mejora medible sin dolor relevante es optimización de algo que a nadie le importa; dolor relevante sin mejora medible es una promesa; y ambos sin adopción son una demo.

Consejo: expresen el valor en la unidad que usa el pagador. Un hospital piensa en horas de personal y camas; una clínica, en turnos e ingresos; un ministerio, en cobertura, oportunidad y equidad.

Una aclaración importante: “negocio” no significa solamente startup. En salud, la sostenibilidad puede venir de un contrato comercial, de un presupuesto público, de un convenio académico o de fondos de cooperación. Lo que no puede faltar es la respuesta a la pregunta de fondo: cuando se termine el entusiasmo del piloto, ¿quién paga —o financia— para que esto siga funcionando?

Modelos posibles de sostenibilidad

Go to market: la puerta de entrada

El canal inicial define la velocidad de tracción. Entrar “al sistema de salud” en abstracto no es una estrategia; entrar por una puerta concreta, sí. Algunas puertas habituales en la región:

• Un hospital piloto con un referente interno que empuje el proyecto.
• Una clínica pequeña o mediana, donde las decisiones son rápidas y el dolor es visible.
• Un municipio con un problema sanitario priorizado y presupuesto propio.
• Un programa sanitario (nacional o provincial) que ya mide el indicador que la solución mejora.
• Una red de prestadores que puede replicar la solución en varios puntos a la vez.
• Un partner tecnológico ya instalado (historia clínica, agenda, facturación) que integre la solución.
• Un financiador u obra social interesado en el resultado (menos ausentismo, mejor adherencia).

Conviene distinguir cuatro familias de métricas, porque responden preguntas distintas y le hablan a audiencias distintas. Las técnicas responden “¿el modelo funciona?”. Las de producto responden “¿la gente lo usa y lo sigue usando?”. Las operativas responden “¿mejora el trabajo real?”. Y las de impacto responden “¿mejora la salud, el acceso o la equidad?” — la pregunta que en definitiva importa en nuestro sector.

Dos consejos prácticos. Primero: elijan pocas métricas —una o dos por familia— y mídanlas desde el primer día del piloto; agregar medición después es carísimo. Segundo: desconfíen de las métricas de vanidad (descargas, likes, visitas, demos realizadas). Suben el ánimo pero no predicen adopción. La métrica honesta es la que dolería mirar si el producto no funcionara.

La trampa más costosa del desarrollo de productos es la aprobación verbal. Todo el mundo responde que sí cuando le preguntan “¿te gustaría una herramienta que…?” — decir que sí es gratis, cortés y no compromete a nada. Por eso la validación seria no se apoya en opiniones sino en acciones, y avanza por tres frentes en orden:

La escalera de la validación

No toda señal vale lo mismo. Esta escalera ordena las señales de menor a mayor compromiso; el objetivo del equipo es subir un escalón por semana, no quedarse a vivir en los primeros dos:

1. Conversación real. Alguien del mundo real acepta hablar del problema con el equipo.
2. Problema reconocido. Esa persona confirma el dolor, lo cuantifica y cuenta qué hace hoy.
3. Prototipo revisado. Alguien dedica tiempo a mirar y criticar un prototipo, aunque sea de papel.
4. Uso simulado o test. Alguien prueba la solución con casos reales o simulados de su trabajo.
5. Piloto acordado. Una institución acepta un piloto con fechas, responsables y criterios de éxito.
6. Pago, presupuesto o sponsor. Alguien compromete dinero, partida presupuestaria o patrocinio interno.
7. Recomendación o expansión. El que usa lo recomienda; el que pagó quiere extenderlo a otra área.

La documentación clínica es uno de los dolores más universales de la práctica médica. No es un problema teórico: le consume al médico cerca del 40% de su tiempo, alarga la jornada, alimenta el burnout y multiplica los errores. Nadie tiene que convencer a un médico de que este problema existe — lo sufre todos los días. Ese es exactamente el tipo de dolor con el que conviene empezar.

El mismo caso, leído con el framework

Lo interesante de este caso no es la tecnología — la transcripción automática existe hace años. Lo interesante es cómo cada componente del framework tiene una respuesta concreta. Esta tabla es el estándar de claridad al que debería aspirar cualquier propuesta del equipo:

El problema que nadie quería resolver

El flujo antes

El circuito manual era una fuga silenciosa y constante de ingresos: WhatsApp manual entre secretaria y paciente; agendas en papel o planillas desactualizadas; sin confirmación automática, y por lo tanto turnos perdidos; cobros informales sin registro ni seguimiento. Nadie lo veía como un problema de IA — era simplemente “cómo se trabaja acá”.

El flujo después

El impacto medible

Lo que enseña M.I.C.A.

Este canvas condensa todo el recorrido de la guía. Cada campo corresponde a una pregunta que el equipo ya sabe responder — o que descubrirá que todavía no puede responder, lo cual es igual de valioso. La regla de uso es simple: escribir en todos los campos, aunque sea con hipótesis. Un campo vacío es una decisión pendiente; un campo con una hipótesis explícita es algo que se puede validar.