Un número creciente de organizaciones de salud están cambiando el paradigma con que desarrollan sus servicios y procesos virtuales, pasando desde una mirada tradicional a una de producto digital. Sin embargo, aún perduran lastres del antiguo paradigma que terminan afectando la experiencia de pacientes y usuarios. ¿Cómo manejamos esos sesgos para que la tecnología solucione de verdad los problemas de quienes llegan vulnerables a atenderse en los centros de salud?

Por Carolina Rojas, Francisco Pardo y Francisco Otondo, consultores de Continuum.

La tradicional mirada de proyecto pone énfasis en el desarrollo de funcionalidades. Su regla es ‘más es mejor’. Sin embargo, tiene tres problemas importantes: no soluciona de verdad los problemas de los usuarios, gasta mucho tiempo en desarrollo y, por lo tanto, aprendemos tarde para corregir o implementar mejoras.

Al final, son los pacientes, el personal clínico y los administrativos quienes sufren.

• Primero, porque el software está hecho según la visión del equipo y no desde la perspectiva de los usuarios, lo que provoca problemas que no son resueltos en un ambiente real.
• Segundo, porque se crean softwares muy complejos. Los usuarios demoran mucho tiempo en manejarlos o simplemente, no aprenden a hacerlo. Así, terminan con dos problemas: el que debía solucionar el programa y el programa en sí mismo.
• Y tercero, porque el desarrollo y diseño demora demasiado. Al tener más funcionalidades, hay que programar y diseñar más. Así, cuando llega al usuario, su necesidad ya cambió y la solución no sirve.

Como respuesta a estos dolores, surge la mirada de producto. Aquí, el foco está en resolver lo más temprano posible los problemas de los usuarios. En la jerga de la industria: entregarles valor temprano.

Pensando el producto

Para ahorrar tiempo y aprender rápido a dar la mejor solución, se lanza un producto mínimo viable (MVP), una versión que sirve para validar con un grupo pequeño si resolvemos el problema o no. Esas primeras mediciones nos guían de acuerdo a lo que valora el usuario. Con esa información, priorizamos lo que de verdad se necesita en lugar de trabajar con hipótesis.

Así, el producto está vivo. Nos centramos, primero, en el problema y aprender. Y, si nos equivocamos, podemos enmendar temprano el camino.

Muchas organizaciones de salud se están sumando a esta tendencia, usando metodologías y frameworks propios de la agilidad. Sin embargo, aún quedan residuos mentales de la mirada tradicional. ¿Qué podemos hacer para abordarlos? Aunque no hay recetas infalibles, porque cada producto y organización es un mundo distinto, podemos entregar seis recomendaciones desde nuestra experiencia.

1. Priorizar, priorizar, priorizar

Cuando estás a cargo de la gestión de una organización de salud sabes que las necesidades de pacientes, clínicos y administrativos son infinitas y los recursos, limitados.

Y sabes que no es algo fácil de comunicar y manejar. Así, la tentación de los equipos de producto es abordar necesidades que se alejan del problema más importante, gastando tiempo, recursos y esfuerzo.

En Continuum, tenemos una metodología propia llamada Core Inception para alinear la organización con los objetivos y métricas de un producto. La hemos ocupado en clínicas, agrupaciones gremiales de salud, laboratorios y otras organizaciones. Y funciona.

Al implementar esta dinámica, nos damos cuenta de lo difícil y necesario que es priorizar. La actividad tiene una etapa donde alineamos objetivos y métricas para luego plasmarlos en un roadmap referencial dividido en tres ventanas de tiempo: corto, mediano y largo plazo. Ahí, les pedimos a los principales interesados que ordenen en una pizarra solo las labores que dan valor a los usuarios y a la vez, al negocio.

Al jerarquizar, aparecen algunas dificultades:

• Los participantes suelen priorizar tareas básicas que deben realizarse, pero que aportan poco a solucionar el problema específico. Están tan concentrados en los requerimientos que dejan para el final aquellas características que afectan más a los usuarios. Y debería ser al revés, priorizar por valor.
• Las personas concentran (casi) todos los objetivos en el corto plazo. Así, no puedes lanzar pronto, porque debes desarrollar y diseñar demasiado. Por eso, es imprescindible definir que solo lo más relevante esté a disposición del público en pocos meses o semanas para testear y mejorar lo antes posible.

Dejar algunas necesidades de lado es un proceso doloroso, porque estamos acostumbrados a llevar adelante proyectos que tienen un final. Un producto nunca lo tiene.

Piensa en Facebook. ¿Te acuerdas cómo era cuando salió? Era muy distinto que su versión actual, porque han ido agregando funciones. En un proyecto, en cambio, aquello que no priorizaste nunca será incluido. Por eso, buscamos agregar todo antes de terminarlo.

La mentalidad de productos se basa en que el producto no termina hasta que deja de usarse. Siempre se vuelven a priorizar desarrollos. Y si lo que postergamos hoy tiene valor en el futuro, se retomará en otro ciclo.

2. No aislar tu servicio

Un error frecuente que hemos visto en salud es que las soluciones se plantean aisladas del resto del proceso que vive un paciente.

La operación de las clínicas, hospitales e, incluso, los consultorios es tan compleja que es difícil visualizar toda la experiencia de vive quien recibe la atención. Se suma a esto que deben coordinarse con otros proveedores de servicios que no están en el core de una organización de salud.

Tu producto puede brindar una excelente experiencia, pero hay problemas antes o después que frustran al usuario. Y con eso, la satisfacción global del paciente se va a la basura.

• Un ejemplo que se repite: en varios desafíos, hemos visto que el problema principal no está en la teleconsulta, la plataforma o la agenda de citas, sino en el proceso de pagos. Por esto, empujamos al cliente a mirar el servicio completo, no solo la etapa o el software en el que partimos trabajando. Eso exige replantear las formas de trabajo.
• Otro ejemplo: en una atención de telemedicina, lo principal es la calidad de la videollamada. Imagina que un paciente tiene una reacción alérgica y el profesional no puede ver con claridad los síntomas cutáneos de la zona. Resolver esto es mucho más relevante que tener una la plataforma de atención ‘bonita’.

Considerando esto, no solo debemos preocuparnos del diseño. También hay que adelantarse a posibles puntos de falla y preocuparse de la integración con otros servicios.

Por eso, es importante tener una mirada orientada al servicio en el equipo.

Con esta visión, podemos mapear el viaje completo del paciente, los profesionales y otros usuarios. Así, analizamos los puntos de dolor y las interacciones de los involucrados con otras unidades y sistemas, entregando la mirada global de su viaje.

Una forma concreta de mapear esta visión global es mediante la definición de un service blueprint

3. Hackear la organización

Pasar de tradicional a ágil requiere un compromiso de toda la organización de salud. Desde el director médico y el gerente general hasta el último a bordo.

Esto no se logra de un día para otro. Lo común es encontrarse con unidades que piensan diferente. Unas sí trabajan en forma colaborativa, con mirada de producto y velando por los resultados del negocio. A otras les sigue acomodando el aislamiento.

¿Cómo hemos vencido estas diferencias? Buscando y generando espacios en la cultura y la estructura de decisión de las organizaciones de salud para lograr objetivos.

Así, hemos sentado en una misma mesa a Finanzas, Administración, Gestión del Paciente, Informática Médica, áreas TI, médicos y profesionales de la salud, Innovación y otras unidades. Incluso, muchas veces hemos necesitado tener el compromiso de la gerencia general y la dirección médica para lograr los cambios.

Pero logramos algo sorprendente: pasamos de silos a equipos multidisciplinarios en días.

Y a pesar de que la colaboración muchas veces no está en su ADN, el resultado es que los participantes terminan dando lo mejor de sí para resolver los problemas más importantes.

4. Ser flexible

Como muchas organizaciones de salud están mal acostumbradas a la mirada de proyecto, los equipos suelen concentrarse en los requerimientos.

Pero en la visión de producto, buscas soluciones a necesidades y problemáticas reales.

Entonces, cuando encuentras a medio camino que el problema más importante es uno que no habías previsto, estás obligado a cambiar.

Un cliente nos confesó a mitad de un desafío que su principal problema no era el que estábamos resolviendo. Lo que más necesitaban era bajar los costos que le generaba tener una plataforma de pagos externa. Esa confesión se dio natural: como ya llevábamos un tiempo trabajando juntos, había más confianza. Lo conversamos y nos enfocamos en ese dolor que no era parte del diagnóstico inicial.

Dar ese golpe de timón es difícil. Es incómodo para clientes y consultores, dejas de hacer tareas que tenías priorizadas y te queda la sensación de que el desafío queda incompleto. Pero lo haces para resolver el problema que más le duele tanto a la organización como a los usuarios. Y eso es lo que vio el cliente que aceptó esta propuesta clave para su estrategia.

5. Atreverse con lo mínimo

Un cliente quería resolver las videollamadas de su sistema de teleconsulta. Traía la solución pensada. Y lo quería así, porque sentía que el nuevo software no podía hacer menos que el antiguo.

Sin embargo, nos dimos cuenta de que el problema que afectaba más al negocio no estaba ahí: estaba en la gestión de los cobros. Los pacientes encontraban que era un proceso lento y engorroso que generaba más incertidumbre que seguridad; pedir los reembolsos de sus seguros o isapres era un dolor de cabeza. Resolver este proceso era clave para el negocio.

Si hubiésemos hecho un producto mínimo, haciendo menos, podríamos haber resuelto el problema principal antes. Al final lo solucionamos, pero tardamos más tiempo porque tuvimos que implementar también el nuevo sistema de videollamadas. Reducimos tiempos en gestión administrativa y permitimos que los pacientes pudieran reembolsar apenas finalizaba su atención remota.

Cuando se crea una ficha clínica electrónica, también pasa algo parecido. La tentación es privilegiar un registro ultra completo y con muchas funcionalidades por sobre la atención y un registro al servicio del paciente.

Entonces, hay que ser valientes para atreverse con un MVP, porque implica desafiar los propios prejuicios y la regla de que ‘más es mejor’.

6. No olvidarse del negocio

¿Por qué un producto digital debe satisfacer las necesidades de un usuario, ya sea un paciente, un clínico o un administrativo? Porque, arreglando sus problemas, la organización de salud adquiere más pacientes, cubre servicios más complejos y reduce sus costos.

Los objetivos y las métricas del negocio mandan. Tener esa conversación en equipo es crucial.

Por ejemplo, cuando desarrollamos un sistema de agendamiento no solo importa medir la cantidad de reservas generadas. Existen otros factores relevantes como el tiempo que gasta el equipo administrativo en el proceso, la desocupación de los médicos, la no presentación de pacientes, la oferta y demandas de las especialidades médicas y otros.

Esas métricas nos indican si estamos generando impacto en el negocio, beneficiando a los pacientes y planificando los cambios en los sistemas. Nos permiten tener un pie en la realidad y no avanzar solo por lo que nos dice nuestra intuición.

***

En Continuum, pensamos en los pacientes de nuestros clientes. Y creemos que el desarrollo productos digitales pensados en el usuario es fundamental para salvar vidas y sanar. ¿Tienes el desafío de llevar tus servicios a otro nivel? Conversemos en hola@continuumhq.com