El medicamento existe. El paciente simplemente no puede encontrarlo.

La escasez de medicamentos crea una experiencia frustrante y a menudo estresante para los pacientes. Una receta puede ser válida. La farmacia puede estar cerca. El medicamento puede existir técnicamente en el mercado. Pero nada de eso importa si el paciente no puede encontrar un lugar que realmente lo tenga en existencia. Para pacientes que lidian con medicamentos de alta demanda o afectados por escasez, el proceso se vuelve manual: llamar a una farmacia, esperar en línea, llamar a otra, repetir, a veces durante horas. MedHound se creó a través de Tech Serving Society, una organización sin fines de lucro enfocada en construir tecnología de beneficio público, para explorar una mejor manera. El proyecto recibió financiamiento para investigar y prototipar un sistema que pudiera reducir el tiempo y la fricción involucrados en localizar medicamentos durante la escasez.

El reto no es simplemente que exista la escasez de medicamentos. Es que la información de disponibilidad está fragmentada. El sistema de salud contiene la información necesaria para resolver gran parte de este problema, pero esa información rara vez se expone de una manera útil para el paciente. Muchas veces los pacientes no tienen una forma confiable de saber:

• qué farmacias cercanas tienen disponible un medicamento
• si una farmacia se quedó sin existencias recientemente
• qué tan reciente es la información de disponibilidad
• si otros pacientes están enfrentando la misma escasez
• si vale la pena llamar o viajar a una ubicación específica

Líder de producto en una iniciativa sin fines de lucro financiada a través de Tech Serving Society, responsable de la estrategia y el diseño de producto.

1. 1.

   Una capa compartida de disponibilidad

   La idea central: ayudar a los pacientes a identificar dónde podrían estar disponibles los medicamentos afectados por escasez antes de empezar a llamar o viajar de farmacia en farmacia. Los usuarios buscan un medicamento y ven información de disponibilidad asociada con ubicaciones de farmacias participantes o reportadas. El producto está diseñado en torno a señales aportadas por la comunidad en lugar de asumir que siempre existirán datos de inventario perfectos en tiempo real. Esas señales muestran dónde se encontró recientemente un medicamento, dónde se reportó como no disponible, qué tan reciente es la información, y qué ubicaciones vale la pena contactar primero. El objetivo no es reemplazar la farmacia; es hacer la búsqueda dramáticamente más eficiente.

2. 2.

   Diseñando en torno a datos imperfectos

   El inventario de las farmacias es dinámico. Un medicamento puede estar disponible a las 9:00 a.m. y desaparecer para el mediodía, así que MedHound no podía presentar la disponibilidad como un hecho permanente; la experiencia tenía que comunicar confianza y qué tan reciente es la información. Eso requirió pensar cuidadosamente en cómo la gente interpreta la información: un reporte de hace diez minutos es diferente de uno de hace tres días, un solo reporte es diferente de varios reportes consistentes, y una escasez confirmada es diferente de un estado desconocido. El principio que surgió de ahí: los datos de disponibilidad deberían comunicar la incertidumbre, no esconderla.

3. 3.

   Colaboración comunitaria como infraestructura

   La colaboración comunitaria no era simplemente una funcionalidad aquí, era parte del modelo de operación. Un paciente que encuentra con éxito un medicamento puede ayudar al siguiente paciente. Un usuario que descubre que una farmacia se quedó sin existencias puede evitar que otros pierdan el tiempo en el mismo viaje. Con el tiempo, cada aporte mejora la utilidad de la red, creando un ciclo de retroalimentación: buscar, confirmar, reportar, ayudar al siguiente paciente. Ese efecto de red es lo que le permite a MedHound funcionar como una capa ligera de información pública alrededor de la escasez de medicamentos.

4. 4.

   Estrategia de producto sin una línea de ingresos

   Debido a que MedHound se desarrolló como una iniciativa sin fines de lucro, la estrategia de producto fue distinta a la de una startup comercial tradicional. La métrica de éxito principal no era el ingreso; era el tiempo ahorrado y la fricción eliminada de la experiencia de salud. Unos minutos ahorrados para un paciente pueden no parecer significativos, pero la escasez de medicamentos afecta a una gran cantidad de personas. Cuando miles o millones de pacientes llaman repetidamente a farmacias, esperan en línea, viajan entre ubicaciones, o contactan a proveedores, el costo acumulado se vuelve enorme. Así que el producto se enfocó en reducir la cantidad de búsqueda innecesaria requerida para encontrar un medicamento.

5. 5.

   Convirtiendo la frustración en un modelo de impacto

   Una manera en que abordé MedHound fue traduciendo la frustración del usuario en impacto económico. Si un paciente pasa aunque sea una hora tratando de localizar un medicamento, ese tiempo tiene valor. Multiplicado en una población grande que enfrenta escasez recurrente, el costo social se vuelve sustancial. Nuestro análisis estimó que reducir el tiempo de búsqueda de medicamentos a escala podría representar más de $1,000 millones en valor de tiempo recuperado. El problema puede sentirse individual cuando alguien está al teléfono con farmacias, pero a escala se convierte en un problema de sistemas, y MedHound fue diseñado para abordar esa ineficiencia a nivel de sistema.

6. 6.

   Diseñando para el beneficio público

   Debido a que el proyecto llegó a través de Tech Serving Society, la accesibilidad y la utilidad pública fueron centrales. El objetivo no era crear otro producto de salud que requiriera que los usuarios ya entendieran el sistema de salud, así que la experiencia se mantuvo simple en torno a una pregunta: ¿dónde debería buscar primero? Eso significó una búsqueda de medicamentos clara, resultados de ubicación sencillos, información reciente de disponibilidad, reportes simples, visibilidad de qué tan reciente es la información, y fricción mínima entre buscar y actuar. La complejidad pertenece detrás del producto; el usuario simplemente debería recibir un mejor punto de partida.

7. 7.

   Equilibrando misión, factibilidad y confianza

   Esto no era ni una herramienta empresarial interna ni un prototipo personal; era una iniciativa sin fines de lucro financiada con una misión de beneficio público, lo que significaba sostener cinco perspectivas a la vez. Necesidad del usuario: ¿el producto realmente facilitaría la búsqueda de medicamentos? Factibilidad técnica: ¿podría recolectarse y mantenerse de forma confiable información útil de disponibilidad? Confianza pública: ¿cómo debería presentarse de forma responsable la información relacionada con la salud? Sostenibilidad: ¿podría el producto operar y crecer sin un modelo de infraestructura costoso? Alineación con la misión: ¿la tecnología mejora el acceso de forma significativa en lugar de simplemente digitalizar un proceso existente?

8. 8.

   Del concepto a la demo en vivo

   El proyecto avanzó más allá de la investigación y la estrategia de producto hacia una demostración pública funcional. MedHound está disponible actualmente como una demo en vivo, permitiendo que usuarios e interesados experimenten el concepto directamente en lugar de evaluarlo a través de una presentación. Ese fue un hito importante: convirtió un proyecto sobre la escasez de medicamentos en algo tangible que podía probarse, demostrarse y mejorarse.

• Muchos de los problemas de producto más difíciles son problemas de coordinación. El medicamento puede ya existir. La farmacia puede ya tenerlo. El paciente puede ya tener la receta. La falla ocurre porque la información correcta no llega a la persona correcta en el momento correcto, y la tecnología puede crear un valor enorme simplemente conectando esas piezas de manera más eficaz.
• La información imperfecta sigue valiendo la pena mostrarla, si se es honesto al respecto. Comunicar confianza y qué tan reciente es la información permite que la gente tome mejores decisiones con datos incompletos, en lugar de crear una falsa sensación de certeza que se derrumba en cuanto cambia el stock de una farmacia.
• El impacto no tiene que ser una línea de ingresos. Los product managers deberían mirar más allá de las métricas de interacción y los embudos de conversión al definir el impacto. A veces la métrica más significativa es cuánta frustración eliminamos del día de alguien.
• Una demo en vivo cambia la conversación. Una vez que la gente pudo usarla, el proyecto dejó de ser un discurso sobre la escasez de medicamentos y se convirtió en algo que podían probar, criticar y mejorar.