De piloto a operación real: qué necesita un proyecto de salud digital para escalar

Un piloto puede funcionar muy bien y aun así no estar listo para escalar. Esa afirmación parece contradictoria, pero explica una parte importante de lo que ocurre en salud digital. Durante un piloto, el equipo suele ser pequeño, los responsables están muy involucrados, los usuarios reciben más soporte, los casos son seleccionados y cualquier problema se resuelve con rapidez porque todos saben que el proyecto está bajo observación. Cuando llega el momento de crecer, cambia la naturaleza del desafío.

Ya no se trata de demostrar que la tecnología puede funcionar. Se trata de comprobar que el modelo puede sostenerse cuando aparecen más sedes, más profesionales, más pacientes, más turnos, más incidencias y menos atención individual del equipo que impulsó el proyecto. Por eso la pregunta correcta al terminar un piloto no es solamente si funcionó.

La pregunta es por qué funcionó y qué tendría que mantenerse para que siga funcionando a mayor escala.

El piloto valida una hipótesis, no toda la operación

Un buen piloto debería responder una pregunta concreta.

• Puede ser si una enfermera en una sede remota puede capturar un examen clínico útil para un médico a distancia.
• Puede ser si una aseguradora consigue que un grupo de afiliados use atención domiciliaria con mayor frecuencia.
• Puede ser si una clínica puede atender pacientes de una sede secundaria sin trasladar especialistas.
• Puede ser si una operación minera reduce derivaciones para cuadros que pueden resolverse localmente.

Si la pregunta está bien formulada, el piloto permite observar comportamiento, identificar fricciones y obtener datos iniciales. El error aparece cuando un resultado positivo se interpreta como autorización automática para multiplicar el proyecto. Escalar introduce variables que el piloto quizás no probó.

• ¿Qué ocurre cuando cambia el turno?
• ¿Qué pasa cuando el coordinador original se va de vacaciones?
• ¿Cómo se capacita a nuevos usuarios?
• ¿El soporte responde con la misma velocidad cuando existen diez sedes?
• ¿Hay suficientes profesionales remotos en horas pico?
• ¿La logística de equipos sigue siendo viable?
• ¿Los indicadores mantienen su comportamiento?
• ¿La experiencia del paciente sigue siendo buena?

La escala revela la robustez del modelo.

Antes de crecer, hay que documentar el workflow que realmente funcionó

En muchos pilotos existe una diferencia entre el proceso diseñado y el proceso que las personas terminan utilizando. El documento inicial puede indicar cinco pasos, pero el personal descubre que uno de ellos genera retrasos y crea una alternativa informal. Un médico puede preferir recibir determinada información antes de conectarse. Una enfermera puede desarrollar una secuencia más eficiente para preparar al paciente. El soporte puede detectar una duda recurrente que nunca apareció durante la capacitación inicial. Todo ese aprendizaje debe capturarse antes de escalar.

La Organización Mundial de la Salud, en su guía de transformación digital para atención primaria, destaca la importancia de mapear workflows, recoger requisitos e involucrar a los trabajadores de salud que utilizarán los sistemas.

Ese principio es especialmente relevante en telemedicina. El flujo real debe convertirse en el estándar operativo del siguiente despliegue.

Escalar personas es diferente de escalar software

Una plataforma puede crear mil usuarios en poco tiempo. Un sistema clínico no se comporta de la misma manera. Los profesionales necesitan comprender qué casos corresponden al modelo, qué información deben capturar, cómo interpretar su rol y cuándo escalar. Los pacientes necesitan saber cuándo utilizar el servicio y qué esperar. Los coordinadores deben poder resolver incidencias. Los líderes locales necesitan asumir responsabilidad sobre la operación. Por eso el escalamiento clínico tiene una dimensión humana que no puede automatizarse completamente.

Un proyecto que crece sin un plan de formación, comunicación y soporte suele aumentar su fricción más rápido que su utilización.

La adopción necesita un sistema, no entusiasmo

Los pilotos suelen beneficiarse del entusiasmo de quienes los lideran. Ese entusiasmo es útil, pero no es escalable. La adopción a gran escala requiere mecanismos repetibles.

• Onboarding claro.
• Capacitación inicial.
• Material de consulta.
• Refuerzos periódicos.
• Seguimiento de utilización.
• Identificación de usuarios que no activaron.
• Soporte con tiempos definidos.
• Comunicación según tipo de usuario.
• Revisión de problemas recurrentes.

TytoCare ha hecho visible este tema mediante Tyto Engagement Labs, un marco que utiliza ciencia del comportamiento para diseñar journeys de activación y uso. Más allá de las métricas específicas del fabricante, el concepto es relevante para cualquier programa de salud digital: la adopción debe gestionarse como una parte del servicio.

Escalar sin indicadores convierte crecimiento en intuición

Antes de agregar nuevas sedes o nuevos usuarios, una organización debería contar con una línea base. No hacen falta decenas de métricas. Hace falta saber qué comportamiento representa éxito.

Para un programa de atención remota podrían ser, por ejemplo, activación de usuarios, utilización recurrente, tiempo de atención, calidad de exámenes, porcentaje de resolución, derivaciones, satisfacción, soporte requerido y costo por caso. Después de escalar, esos indicadores deben compararse por sede, turno, población o equipo.

Si una nueva sede tiene una utilización mucho menor, el problema puede estar en capacitación, demanda, disponibilidad médica o diseño del proceso. Sin esa visibilidad, la organización solo sabe que el volumen total subió o bajó. No sabe por qué.

La capacidad clínica debe crecer al mismo ritmo que la demanda

Una de las formas más rápidas de deteriorar la experiencia es aumentar puntos de acceso sin aumentar o redistribuir la capacidad profesional que los atiende. La telemedicina puede ayudar a balancear recursos, pero no crea horas médicas de la nada.

Si un programa pasa de dos puntos remotos a veinte, debe estimar cuántos casos aparecerán, en qué horarios y con qué complejidad. Puede ser necesario definir ventanas de atención, turnos dedicados, modelos asincrónicos para determinados casos o reglas de prioridad.

El 2026 Urgent Care Virtual Summit de TytoCare insistió precisamente en que la atención virtual ya no debe verse como una línea separada, sino como una forma de balancear capacidad entre canales presenciales y remotos.

La escala funciona mejor cuando el recurso clínico se administra como una red y no como una agenda aislada.

El soporte debe convertirse en operación formal

Durante un piloto, una llamada directa al responsable del proyecto suele resolver casi cualquier cosa. Ese modelo no puede crecer. La organización necesita saber quién atiende una incidencia de primer nivel, quién escala un problema técnico y cuándo interviene el fabricante o proveedor especializado. También necesita distinguir incidentes técnicos de dudas de uso.

Una contraseña olvidada, una falla de conectividad, un examen mal realizado y una caída de plataforma son problemas diferentes. Cada uno requiere una respuesta distinta. Un sistema de soporte maduro evita que cualquier dificultad termine escalando innecesariamente a la misma persona.

La logística aparece cuando el piloto deja de ser pequeño

La tecnología médica tiene una realidad física. Los dispositivos deben estar disponibles, cargados, limpios, protegidos, identificados y, cuando corresponde, mantenidos. Pueden existir accesorios de consumo, baterías, fundas, tablets u otros componentes. En una sola sede, ese control puede ser informal. En una red, necesita responsables y procedimientos.

Escalar implica pensar en inventario, reemplazos, contingencia, transporte, limpieza, disponibilidad por turno y trazabilidad de los equipos. La experiencia del usuario puede deteriorarse por un detalle logístico aunque la plataforma funcione perfectamente.

Los costos también cambian con la escala

Un piloto puede tener costos que no representan el escenario futuro. Puede recibir descuentos, usar personal existente o absorber soporte dentro del proyecto. Antes de crecer conviene reconstruir el costo operativo real.

• Licenciamiento.
• Equipos.
• Conectividad.
• Personal.
• Capacitación.
• Soporte.
• Logística.
• Reposición.
• Gestión del programa.

La escala debería mejorar la eficiencia, pero solo si el modelo está diseñado para ello. Un proyecto con baja utilización puede parecer barato por dispositivo y resultar caro por consulta efectivamente realizada.

La gobernanza determina si el proyecto sobrevive al piloto

Cuando una innovación depende de una sola persona, sigue siendo un proyecto. Cuando existe un responsable clínico, uno operativo, indicadores, soporte, presupuesto, protocolos y revisión periódica, empieza a convertirse en servicio. La gobernanza no necesita ser burocrática. Necesita ser clara.

• Quién decide cambios.
• Quién revisa métricas.
• Quién responde por la calidad clínica.
• Quién administra usuarios.
• Quién gestiona incidencias.
• Quién aprueba una nueva sede.
• Quién puede detener temporalmente una operación si existe un riesgo.

Esa claridad protege la sostenibilidad.

El escalamiento debería ocurrir por etapas

Crecer de un piloto a toda una organización en un solo movimiento aumenta el riesgo de perder aprendizaje. Una alternativa más sólida es ampliar en etapas.

1. Primero se valida el caso de uso.
2. Después se prueba en un segundo contexto con condiciones diferentes.
3. Luego se estandariza el workflow.
4. Se ajustan capacitación y soporte.
5. Se define una línea base de indicadores.
6. Recién entonces se amplía a una red mayor.

Cada etapa debe responder una pregunta nueva.

Un proyecto escalable puede explicar su propia lógica

Antes de crecer, una organización debería poder describir en pocas frases por qué su modelo funciona.

• Qué problema resuelve.
• Para qué paciente sirve.
• Quién lo opera.
• Qué información clínica produce.
• Qué decisión habilita.
• Cómo se mide.
• Qué soporte necesita.
• Cuánto cuesta.

Si esas respuestas dependen de conocimiento tácito de unas pocas personas, todavía existe trabajo por hacer. En MUNZ entendemos la implementación como una secuencia que incluye diseño asistencial, selección tecnológica, puesta en marcha, capacitación, adopción y soporte. La tecnología puede ser internacional, pero el modelo debe funcionar dentro de la realidad local de cada organización. Un piloto demuestra que una idea puede funcionar. Escalar demuestra que la organización aprendió a operarla.

Fuentes consultadas

1. Organización Mundial de la Salud. Digital transformation handbook for primary health care.

2. Organización Mundial de la Salud. Digital Implementation Investment Guide.

3. Organización Mundial de la Salud. Monitoring and evaluating digital health interventions.

4. TytoCare. Tyto Engagement Labs.

5. TytoCare. Urgent Care Virtual Summit 2026.

6. TytoCare. Beyond geography: Scalable care models for access, workforce and sustainability.