Implementar tecnología médica es mucho más que comprar dispositivos

Una de las conversaciones más habituales cuando una organización comienza a evaluar tecnología médica gira rápidamente alrededor del dispositivo. Qué equipo necesitamos, cuántas unidades deberíamos adquirir, cuánto cuesta y cuánto tiempo demorará implementarlo. Son preguntas necesarias, pero rara vez son las primeras que deberían formularse. Cuando una institución de salud, una aseguradora, una empresa o una red asistencial incorpora una nueva tecnología, el verdadero desafío no consiste en comprarla. Consiste en transformar esa capacidad tecnológica en un servicio que pueda funcionar de manera consistente dentro de la operación cotidiana. Esta diferencia explica por qué existen proyectos construidos alrededor de excelentes tecnologías que terminan utilizándose poco, mientras otros consiguen integrarse al modelo asistencial y crecer durante años.

Después de trabajar con diferentes soluciones de tecnología médica, mi conclusión es bastante clara: un dispositivo puede funcionar perfectamente y, aun así, la implementación puede fracasar. El problema no necesariamente está en el producto. Muchas veces está en todo lo que no fue diseñado alrededor de él.

La tecnología no es el servicio

Un dispositivo para realizar examen físico remoto no constituye por sí solo un servicio de telemedicina. Un sensor capaz de registrar presión arterial durante 24 horas tampoco representa automáticamente un programa de diagnóstico o seguimiento. Del mismo modo, un wearable que genera parámetros fisiológicos no equivale a un servicio de monitoreo remoto de pacientes. La tecnología aporta una capacidad. El servicio aparece cuando esa capacidad se integra dentro de un proceso clínico que define quién utiliza la herramienta, cuándo se utiliza, qué información produce, quién interpreta esa información y qué ocurre después.

Las recomendaciones internacionales sobre salud digital insisten precisamente en este punto. La implementación de telemedicina exige analizar necesidades clínicas, infraestructura, procesos asistenciales, operación, adopción, inversión y evaluación. La compra representa únicamente una etapa dentro de un sistema mucho más amplio. En otras palabras, comprar tecnología es una transacción. Implementarla implica diseñar una forma distinta de trabajar.

El proyecto debería comenzar por el problema

Antes de discutir qué dispositivo necesita una organización, conviene entender qué situación intenta resolver. Puede necesitar reducir traslados, conectar sedes alejadas con especialistas, mejorar el seguimiento después de un alta, atender trabajadores ubicados en operaciones remotas, aumentar capacidad diagnóstica, reducir tiempos de espera o acompañar pacientes sin obligarlos a desplazarse continuamente. Cada uno de estos problemas conduce a un modelo diferente. También conduce a indicadores, responsabilidades y flujos diferentes.

Cuando una organización empieza por el dispositivo existe el riesgo de terminar buscando dónde utilizarlo. Cuando comienza por el problema puede determinar qué capacidad tecnológica necesita y qué proceso debe construir alrededor de ella. Esa secuencia cambia significativamente la probabilidad de éxito.

TytoCare permite observar con claridad esta diferencia

TytoCare permite realizar a distancia componentes del examen físico como auscultación de corazón, pulmones y abdomen, evaluación de oído, garganta, piel y temperatura. Es una capacidad tecnológica relevante, pero adquirir el dispositivo no significa que una organización tenga automáticamente un servicio de telemedicina. Hay que definir dónde estará el equipo, quién realizará el examen, quién será el médico remoto, cómo llegará la consulta, qué pacientes pueden utilizar el modelo y cuánto tiempo tendrá el profesional para responder. También hay que definir qué ocurre cuando aparece un hallazgo que requiere atención presencial y quién será responsable del funcionamiento cotidiano del servicio.

En la página de TytoCare en MUNZ pueden observarse distintos modelos de implementación y sectores. La misma tecnología puede utilizarse dentro de un programa domiciliario, una red descentralizada, una operación de salud ocupacional o un punto de atención que necesita conectarse con especialistas.

Lo que cambia no es necesariamente el dispositivo. Cambian el problema, el usuario, la operación y la forma en que se genera valor.

El comprador, el usuario y el beneficiario pueden ser distintos

Una de las complejidades de HealthTech es que quien paga una tecnología no siempre es quien la utiliza directamente. Una aseguradora puede contratarla, un médico interpretar la información, una enfermera realizar el examen y el paciente recibir el beneficio. Sistemas puede mantener la plataforma, innovación puede haber impulsado el proyecto y una dirección médica o financiera puede decidir finalmente si el programa continúa. Cuando cualquiera de esos actores queda fuera del diseño, aparecen dificultades.

La dirección puede considerar que la tecnología es estratégica mientras los médicos perciben que añade carga de trabajo. El paciente puede valorar la experiencia, pero la organización puede no tener un modelo económico para sostenerla. El equipo médico puede considerar útil la información, pero nadie haber definido quién debe revisar cada resultado. Por eso la adopción de tecnología médica no es solamente un problema técnico. Es un problema de alineamiento organizacional.

El flujo médico condiciona la adopción

Los profesionales de salud ya trabajan dentro de procesos complejos: agenda, historia clínica, resultados, interconsultas, prescripciones, alertas y seguimiento. Cuando una nueva tecnología introduce otra plataforma, otra contraseña, otra bandeja de entrada o una nueva tarea, la fricción aumenta. Algunas implementaciones comienzan a perder tracción precisamente en este punto, aunque el producto sea sencillo de utilizar. Una buena implementación debe analizar desde el principio cómo llegará la información al médico, qué necesita revisar, qué genera una alerta, quién prioriza y qué información debe quedar integrada a la historia clínica. La tecnología empieza a formar parte de la práctica cuando deja de sentirse como un proceso adicional y comienza a incorporarse al flujo habitual del profesional.

Capacitar no significa conseguir adopción

Una persona puede aprender perfectamente a utilizar un dispositivo durante una capacitación y no volver a utilizarlo después. Eso demuestra que conoce el procedimiento, pero no que la tecnología haya sido adoptada. La adopción aparece cuando la herramienta resuelve un problema concreto dentro de una rutina real. En salud ocupacional, el personal necesita saber qué casos puede manejar mediante atención remota y cuáles deben derivarse. En una red descentralizada, una enfermera debe conocer cómo preparar al paciente, realizar el examen y conectarse con el médico. En atención domiciliaria hay que coordinar desplazamiento, evaluación y respuesta clínica. En monitoreo remoto, además, alguien tiene que interpretar la información y actuar cuando corresponde.

La tecnología empieza a generar valor cuando deja de ser una novedad y se convierte en una forma normal de trabajar.

Los indicadores deben definirse antes de empezar

Una implementación que no define cómo medirá sus resultados corre el riesgo de terminar evaluándose mediante percepciones. Que a los médicos les haya gustado, que los pacientes estén satisfechos o que el equipo funcione correctamente son datos útiles, pero no permiten saber por sí solos si el proyecto resolvió el problema original.

Si una institución implementa telemedicina para reducir traslados, debería medir traslados. Si busca ampliar acceso, necesita medir cobertura y tiempo hasta la atención. Si quiere aumentar capacidad resolutiva, debe saber cuántos casos pueden concluir dentro del modelo y cuántos necesitan atención presencial. En monitoreo remoto pueden ser relevantes adherencia, calidad de las mediciones, alertas gestionadas, tiempos de respuesta y resultados clínicos. Los KPIs deben salir del problema que justificó el proyecto, no de las características del dispositivo.

Los benchmarks sirven como referencia, no como promesa

Los resultados obtenidos por otras organizaciones pueden ayudar a construir hipótesis y establecer objetivos iniciales. La página de TytoCare en MUNZ recoge diferentes referencias internacionales y muestra indicadores relacionados con utilización de servicios, capacidad asistencial y ausentismo en determinados modelos. Estos datos son útiles porque permiten entender qué variables pueden cambiar cuando una implementación funciona. No deben interpretarse como una promesa de que toda organización peruana obtendrá exactamente el mismo resultado. Un benchmark indica qué vale la pena observar. Los resultados locales son los que finalmente determinan si el modelo funciona dentro de una organización específica.

El monitoreo remoto plantea exactamente el mismo desafío

El mismo principio se observa cuando dejamos la telemedicina y pasamos al monitoreo de pacientes. Biobeat utiliza un sensor torácico para realizar monitoreo ambulatorio de presión arterial sin un brazalete inflable y generar información longitudinal que posteriormente puede ser revisada por el especialista. En Biobeat en Perú de MUNZ se explica el funcionamiento del sistema y sus aplicaciones clínicas. La capacidad tecnológica es interesante, pero nuevamente hay que diseñar todo lo que ocurre alrededor del dato. Quién coloca el sensor, cómo comienza el estudio, quién recibe el reporte, qué profesional lo interpreta, cómo llega el resultado al proceso clínico y qué sucede si aparece un hallazgo que necesita seguimiento.

La transformación no consiste únicamente en cambiar un brazalete por un sensor. Consiste en rediseñar un proceso aprovechando una nueva capacidad tecnológica.

El soporte forma parte de la experiencia clínica

Cuando una implementación empieza a operar aparecen situaciones que normalmente no ocupan mucho espacio en una presentación comercial. Una aplicación necesita actualizarse, una contraseña deja de funcionar, la batería está descargada, la conectividad es insuficiente o un profesional capacitado deja la organización. También puede ocurrir que un nuevo usuario necesite acceso o que una plataforma requiera una configuración adicional. Son situaciones normales. Lo importante es que el modelo haya definido quién las resuelve, por qué canal y en qué plazo. Cuando una consulta depende de una tecnología y esa tecnología se detiene, el soporte deja de ser exclusivamente un problema informático. Pasa a formar parte de la continuidad del servicio asistencial.

Integrar no significa integrar todo desde el primer día

La integración es uno de los conceptos más mencionados en salud digital, y con razón. Los datos clínicos no deberían permanecer indefinidamente aislados en plataformas independientes. Sin embargo, también conviene mantener una mirada pragmática.

Una integración puede requerir desarrollo, APIs, seguridad, validaciones, pruebas, mantenimiento y presupuesto. En una red de gran escala puede ser indispensable desde el comienzo. En un modelo que todavía está demostrando utilización puede no ser la primera prioridad. Integrar demasiado pronto puede aumentar considerablemente la complejidad antes de saber si el modelo funciona. Integrar demasiado tarde puede convertirse en una barrera cuando llega el momento de escalar. La arquitectura tecnológica debe acompañar la madurez del servicio.

Los pilotos solo tienen sentido cuando conducen a una decisión

Los pilotos pueden ser útiles cuando existe una pregunta concreta que responder. La organización debería saber qué intenta validar, con qué población, durante cuánto tiempo, mediante qué indicadores y qué decisión tomará cuando termine el periodo de evaluación.

Cuando nada de esto está definido, el piloto puede convertirse en una forma cómoda de mantener una tecnología indefinidamente en evaluación. Eso produce pocas unidades, poca utilización, escasos datos y ninguna decisión de escala. Me parece más útil pensar en implementaciones controladas con criterios de decisión. El objetivo no es comprobar que el dispositivo funciona. Esa capacidad debería estar validada previamente. Lo que necesitamos saber es si el modelo funciona dentro de esa organización.

Una implementación necesita un responsable

Alguien tiene que ser responsable del resultado. Puede ser una dirección médica, operaciones, innovación o una unidad de negocio. Lo importante es que exista una persona o un equipo que pueda observar utilización, incidencias, tiempos, indicadores y evolución. Cuando una tecnología pertenece conceptualmente a muchas áreas pero ninguna es responsable de su adopción, el entusiasmo inicial suele disminuir y la utilización comienza a caer. La implementación necesita un propietario operativo, no solamente un comprador.

Escalar significa poder repetir lo que funcionó

Una implementación puede funcionar muy bien en una sede porque existe una enfermera especialmente comprometida, un médico entusiasta y un gerente involucrado personalmente. Eso demuestra que el servicio puede funcionar, pero todavía no demuestra que sea escalable. La prueba aparece cuando el modelo puede reproducirse en una segunda sede, una décima o una centésima sin depender exactamente de las mismas personas.

La madurez empieza cuando aparecen procesos repetibles en capacitación, soporte, implementación, indicadores y responsabilidades. También necesita un modelo económico que permita sostener el crecimiento. En ese momento, la experiencia acumulada deja de pertenecer únicamente a quienes participaron en los primeros proyectos y empieza a convertirse en una capacidad de la organización.

HealthTech no debería medirse por cuánta tecnología compramos

Una organización puede tener cientos de dispositivos y una utilización marginal. Otra puede disponer de menos tecnología y haber transformado por completo una ruta asistencial. La diferencia está en lo que ocurre después de la compra.

Desde MUNZ trabajamos precisamente con esa lógica al desarrollar tecnologías internacionales como TytoCare y Biobeat en Perú. El objetivo no debería limitarse a colocar dispositivos, sino a comprender dónde pueden generar valor, qué modelo asistencial los sostiene y qué indicadores permiten demostrar resultados. Es también el enfoque que desarrollo en la sección de HealthTech de este sitio: tecnología, mercado y capacidad de ejecución deben avanzar de manera coordinada.

En Perú necesitamos desarrollar capacidad de implementación

Existe hoy una oferta internacional extraordinaria en telemedicina con examen físico remoto, monitoreo ambulatorio, wearables, inteligencia artificial, diagnóstico digital y atención domiciliaria conectada. Nuestro reto no será solamente acceder a estas tecnologías. Será incorporarlas correctamente dentro de organizaciones que tienen procesos, incentivos y limitaciones concretas.

Eso exige conocimiento clínico, entendimiento del mercado, operación, tecnología y gestión. Una organización no necesita otro dispositivo guardado en un gabinete. Necesita resolver un problema. La verdadera implementación empieza cuando la herramienta deja de ser parte de una demostración y empieza a utilizarse durante un día normal, con pacientes reales, incidencias reales y decisiones clínicas reales. Cuando, después de varios meses, la organización puede medir lo ocurrido y decide que esa nueva forma de trabajar merece continuar, la tecnología deja de ser un proyecto de innovación y empieza a convertirse en parte del sistema de atención.

Esa es, para mí, la diferencia entre comprar tecnología médica e implementar HealthTech de verdad.

Referencias

World Health Organization. Consolidated telemedicine implementation guide.

MUNZ. TytoCare en Perú.

MUNZ. Biobeat en Perú.

MUNZ. Tecnología médica y salud digital.