WhatsApp Business API en sanidad: lo que hemos aprendido construyendo Aedevita
Por qué WhatsApp en salud no es una idea tan rara
Cuando propusimos WhatsApp como canal principal de Aedevita, la plataforma de triaje dermatológico que construimos para la Asociación Española de Dermatología y Venereología, la primera reacción de parte del equipo médico fue escéptica. WhatsApp no parece el lugar natural para una herramienta clínica: es donde se comparten memes y fotos familiares, no donde se recibe orientación sanitaria.
Pero los números cambian la perspectiva. Según datos de Statista y del INE, más del 85% de la población adulta española usa WhatsApp diariamente, con tasas cercanas al 95% en los tramos de 25 a 55 años. Es la única app de comunicación con penetración prácticamente universal en España, incluyendo segmentos demográficos —mayores de 65, usuarios de bajos ingresos, población rural— que no se instalan apps específicas y rara vez abren un navegador para usar una webapp.
No requiere registro. No requiere instalación adicional. No hay barrera cognitiva de aprender una interfaz nueva. Para un servicio que quiere llegar a pacientes con lesiones cutáneas que no saben si necesitan ver a un médico urgente o pueden esperar, esa accesibilidad tiene valor clínico real: reduce la barrera de acceso para poblaciones que no tienen dermatólogo privado ni quieren colapsar urgencias por algo que puede ser banal.
La alternativa habitual es una app móvil dedicada. Las apps de salud tienen tasas de retención muy bajas: la media del sector en el primer mes ronda el 8%, y para servicios de uso ocasional —como el triaje dermatológico— cae aún más. Pedir a un paciente que instale una app para un servicio que usará una vez al año es una fricción que se traduce directamente en abandono. WhatsApp no tiene ese problema: el canal ya está instalado.
API oficial vs. soluciones no oficiales: no es una elección real
Existe una distinción crucial que no siempre es obvia al principio: WhatsApp Business API —la API oficial de Meta para empresas— frente a soluciones no oficiales que funcionan emulando un cliente de WhatsApp.
Las soluciones no oficiales son baratas, rápidas de integrar y técnicamente funcionales. También violan los términos de servicio de WhatsApp, lo que significa que Meta puede cerrar el número en cualquier momento sin previo aviso. Para una herramienta de consumo con baja criticidad eso podría ser aceptable. Para una plataforma de triaje médico, donde los pacientes esperan respuestas sobre lesiones que les preocupan y los dermatólogos construyen su confianza sobre la estabilidad del canal, la posibilidad de que el canal se cierre de un día para otro es inaceptable.
Además, operativamente son opacas. No hay SLAs, no hay soporte, no hay garantías. Si Meta cambia sus mecanismos de detección —lo hace periódicamente— todas las integraciones no oficiales quedan afectadas al mismo tiempo. Hemos visto proveedores perder el acceso durante días, con todos sus clientes a ciegas.
La API oficial requiere aprobación de Meta, tiene costes por conversación (diferenciados por categoría: marketing, utilidad, autenticación, servicio) y tiene restricciones técnicas que las no oficiales ignoran. Pero ofrece algo fundamental: estabilidad contractual y soporte. Cualquier implementación seria de WhatsApp en salud debe usar la API oficial, aunque el tiempo de activación sea semanas en lugar de horas.
Ventanas de 24 horas y el diseño de la conversación
WhatsApp Business API distingue entre mensajes de plantilla y mensajes de sesión. Los mensajes de plantilla —los que la empresa envía para iniciar conversación o contactar a alguien que no ha escrito primero en las últimas 24 horas— deben ser pre-aprobados por Meta. Los mensajes de sesión son libres dentro de una ventana de 24 horas desde el último mensaje del usuario.
Esta arquitectura cambia cómo tienes que diseñar los flujos. Si un paciente inicia un triaje, envía su foto, y no responde durante 26 horas, la ventana ha cerrado. Para continuar la conversación necesitas una plantilla aprobada. Diseñar el flujo de Aedevita significó pensar en qué pasaba cuando los tiempos de respuesta del usuario eran irregulares —son casi siempre irregulares en salud— y qué plantillas de seguimiento había que pre-aprobar con Meta.
El proceso de aprobación de plantillas merece mención especial. Meta revisa manualmente todas las plantillas. Los tiempos varían entre 24 horas y varios días. Los rechazos por razones que no siempre están bien documentadas son frecuentes. El vocabulario médico, en particular, activa con frecuencia revisiones más lentas o rechazos por "contenido sensible". Planificar con margen y preparar variaciones alternativas de cada plantilla es práctica esencial: hemos tenido casos donde una versión con "examinar" era rechazada y la misma plantilla con "revisar" pasaba sin incidencias.
La consecuencia de producto es que los flujos de WhatsApp en salud no pueden asumir sincronía. Tienen que poder retomarse tras días o semanas, con plantillas que recuerden amablemente al paciente dónde se quedó el proceso, y con una capacidad de retry y recordatorio que no se sienta intrusiva pero tampoco abandone al usuario.
Imágenes médicas: compresión, cadena RGPD, pipeline de visión
Aedevita recibe fotografías de lesiones cutáneas. Esto plantea un conjunto de problemas técnicos y regulatorios específicos que no aparecen en los tutoriales estándar de WhatsApp Business API.
El primero es técnico. WhatsApp comprime las imágenes automáticamente cuando se envían por el canal estándar. Para uso médico, donde la calidad de imagen afecta la precisión de la clasificación por visión artificial, hay que diseñar el flujo de captura y envío para minimizar esa pérdida. La instrucción al paciente sobre cómo fotografiar la lesión —distancia, iluminación, encuadre, incluir una referencia de escala cuando sea posible— es parte del producto, no un detalle de UX. En Aedevita probamos varias versiones de las instrucciones iniciales antes de dar con una que producía fotografías utilizables el 85% de las veces.
El segundo es regulatorio. Una imagen de una lesión cutánea asociada al número de teléfono del paciente es un dato de salud bajo RGPD, categoría especial. La cadena de procesamiento completa —desde que Meta recibe la imagen en sus servidores hasta que está en los nuestros, pasando por el modelo de visión artificial y por cualquier servicio de storage o CDN intermedio— debe estar documentada como cadena de subprocesadores en el Registro de Actividades de Tratamiento. Cada eslabón requiere un acuerdo de procesamiento firmado.
El tercero es el pipeline de visión en sí. Desde una imagen recibida por WhatsApp hasta un score de clasificación de riesgo hay varios pasos: descarga con autenticación y timeout, validación de formato y calidad, detección de la lesión dentro de la imagen (segmentación), extracción de features por el modelo de visión, clasificación contra taxonomía dermatológica, y generación del output estructurado. Cada paso tiene sus propios failure modes: imágenes borrosas, lesiones que no se detectan porque están cubiertas por pelo, fotografías que no son de piel humana.
Validación clínica: precisión no es lo mismo que relevancia clínica
La parte técnica más compleja de Aedevita no fue la integración con WhatsApp ni la arquitectura backend. Fue el proceso de validación clínica del modelo de clasificación.
Los dermatólogos que colaboraron en el proyecto son el verdadero motor del sistema. El modelo no se entrena con imágenes de internet: se entrena con un dataset etiquetado por especialistas, con acuerdo interrater medido y documentado. Cada release del modelo pasa por evaluación en un conjunto de test reservado que no se toca durante el entrenamiento. Los resultados —sensibilidad, especificidad, y especialmente el comportamiento en casos de lesiones atípicas o fuera de distribución— se presentan al comité médico antes de cualquier despliegue.
Pero la precisión estadística no es suficiente. Los dermatólogos añadieron un criterio que los equipos técnicos muchas veces pasan por alto: la relevancia clínica del error. Un falso positivo en una clasificación de urgencia (el modelo dice "urgente" para una lesión banal) genera una consulta innecesaria pero no es peligroso. Un falso negativo en el extremo contrario (el modelo dice "banal" para un melanoma incipiente) puede ser grave. La función de pérdida del modelo y los umbrales de decisión se ajustaron para privilegiar sensibilidad sobre especificidad en las categorías de mayor riesgo, aunque eso empeorara la precisión global.
Este tipo de ajuste solo emerge del diálogo continuo entre ingenieros de ML y clínicos. Sin esa conversación, el modelo optimiza lo que es fácil de medir, no lo que es clínicamente importante.
La realidad operativa: 200 conversaciones simultáneas
Los tutoriales asumen condiciones estables. La realidad de producción trae picos imprevisibles. En una ocasión, durante una feria de salud donde Aedevita estaba difundiéndose a profesionales y pacientes como demostración, el sistema recibió más de 200 conversaciones simultáneas en dos horas. Hasta ese momento el ritmo habitual era de decenas por hora.
El sistema aguantó, pero no sin tensión. Las colas de procesamiento de imágenes se llenaron. Los tiempos de respuesta se alargaron. Detectamos en caliente que nuestra política de rate limiting con Meta era menos generosa de lo que asumíamos. Y descubrimos que el autoscaling del servicio de visión tenía un cold start de casi un minuto que no habíamos caracterizado bien en pruebas.
La respuesta post-incidente cambió varias cosas: warm pools para evitar cold starts, reconfiguración de rate limits con Meta, separación de la cola de procesamiento de imágenes en dos —prioritaria para usuarios activos, background para retries—, y runbooks específicos para eventos previsibles como ferias, campañas de comunicación o apariciones en medios.
Framing: IA que asiste, no IA que reemplaza
Una decisión de comunicación influye directamente en la adopción clínica: cómo se presenta la función de la IA. Un sistema que "diagnostica" o "decide" genera resistencia inmediata en el colectivo médico, con razón. Un sistema que "prioriza y orienta, con validación dermatológica" genera una conversación completamente distinta.
En Aedevita, el output no es un diagnóstico. Es una clasificación de urgencia —requiere atención urgente, consulta ordinaria, puede monitorizarse— con la recomendación explícita de derivar a especialista cuando hay duda. El dermatólogo recibe el análisis como contexto adicional, no como instrucción. Esa distinción no es solo framing: está integrada en el diseño del producto, en cómo se presenta la información al paciente, y en cómo se registra la decisión final en el sistema.
Los proyectos de IA en salud que fracasan no suelen hacerlo por limitaciones técnicas. Fracasan porque el framing fue incorrecto desde el principio, o porque los clínicos nunca se sintieron parte del diseño. Construir sobre WhatsApp resolvió la barrera de acceso al paciente; construir con dermatólogos resolvió la barrera de confianza en el sistema. Las dos son condición necesaria.
¿Quieres llevar esto a tu empresa?
Cuéntanos tu proyecto y te ayudamos a encontrar la solución tecnológica adecuada.
Hablar con nuestro equipo