¿Le han enseñado un demo americano que no conoce Adeslas?
Alternativa al software de prior authorization de EE.UU. en clínicas españolas
El mercado estadounidense de automatización de prior authorization está capitalizado (Cohere, Humata, Latent, Anterior, Element5 y otros). Son referencias técnicas serias. Trasladarlos a una policlínica española choca con un hecho de mercado: no hay API FHIR de autorización previa en las aseguradoras privadas españolas, y el trabajo ocurre en portales del profesional heterogéneos.
El software de prior auth de EE.UU. optimiza un flujo con payers, EDI y denegaciones post-acto distintas a las españolas. SaludComply está diseñado para la autorización previa en portales españoles (Adeslas, Sanitas, ASISA, DKV, Mapfre), con aprobación humana y sin pretender ser un producto americano “localizado”.
Qué hace bien Software de prior auth de EE.UU.
Madurez de producto, capital y aprendizaje en denegaciones a escala. Element5 Neos, por ejemplo, es una prueba de existencia del patrón agente + navegador en prior auth (EE.UU., post-acute, enero 2025). Útil como referencia de arquitectura, no como competidor en Barcelona.
Dónde se queda corto para autorizaciones previas
Sin corpus de reglas por aseguradora española, sin soporte de portales locales y, en muchos casos, con comprador del lado del payer (aseguradora), no del prestador. Anterior es un ejemplo de automatización del lado del pagador: no es el mismo lado de la mesa.
Para quién es
Compradores de grupos hospitalarios que evalúan vendors internacionales y necesitan un criterio claro de encaje en España.
Para quién no es
Clínicas que solo comparan gestorías locales: esta página es para el filtro “¿me sirve un vendor US?”.
Comparativa
| Dimensión | Software de prior auth de EE.UU. | SaludComply |
|---|---|---|
| Mercado de diseño | EE.UU. (payers / providers US) | Sanidad privada española |
| API estándar de PA | Ecosistema US (EDI / APIs payer) | Portales; sin API FHIR PA pública en ES |
| Adeslas / Sanitas / ASISA | No nativo | Objetivo de producto |
| Lado del comprador | A menudo payer o health system US | Clínica / policlínica / grupo privado ES |
| Capital y escala | Muy alta | Producto enfocado, mercado local |
| RGPD y encargados ES | Requiere adaptación | Diseño con RGPD Art. 28 en mente |
Lo que cambia en la práctica
El problema español es el portal, no solo la denegación
En España la adjudicación pesa en la autorización previa. Si esa solicitud sale mal, el remedio post-acto es limitado. Por eso el producto mira portales y caducidades, no solo “appeal letters” al estilo US.
Respeto técnico, sin postureo
Citamos a esos equipos como pares técnicos cuando hablamos de umbrales de calidad. No fingimos que “ya estamos en el Series C americano”. El comprador español necesita portales que funcionen el lunes.
Ventana de mercado
Mientras no exista estandarización UNESPA/ICEA/ASPE de API de autorización, el trabajo portal a portal sigue siendo la realidad. Eso puede cambiar; hoy no está en Categoría Prioritaria 1 del EHDS.
Preguntas frecuentes
- ¿Puedo comprar Cohere o Humata para mi clínica en Madrid?
- No hay señal pública de un producto prestador-side listo para portales españoles (TO_VERIFY en el tiempo). Aunque existiera licencia, el corpus de reglas y los portales habría que reconstruirlos.
- ¿Element5 es competencia?
- No en España. Es la prueba de que el patrón de agente sobre navegador puede vivir en producción en prior auth. Mercado y vertical distintos.
- ¿El EHDS solucionará las autorizaciones?
- El Reglamento (UE) 2025/327 no incluye autorización previa en Categoría Prioritaria 1. El EHDS importa para interoperabilidad clínica; no sustituye los portales de Adeslas o Sanitas en 2026.