Cómo construiría un sistema de autorización previa con IA que nunca firme la denegación

Respuesta Directa

La autorización previa es la aprobación que exige una aseguradora antes de pagar un procedimiento, un fármaco o un dispositivo. Hoy funciona con faxes, esperas telefónicas y una persona que compara manualmente un historial con un PDF de reglas clínicas. Una versión nativa en IA redacta la solicitud y hace seguimiento del caso; un revisor colegiado sigue siendo dueño de la decisión de aprobar o denegar, porque dos normas de 2025-2026 ya lo dicen por escrito.

Puntos Clave

• Los médicos y su personal dedican una media de 13 horas semanales a autorizaciones previas, y el 94% dice que contribuye al desgaste profesional, según la encuesta a médicos de la AMA de 2025.
• Desde el 1 de enero de 2026, la norma de interoperabilidad de CMS (CMS-0057-F) obliga a las aseguradoras afectadas a resolver las solicitudes urgentes en 72 horas, las ordinarias en 7 días, y a indicar un motivo concreto de denegación.
• La Physicians Make Decisions Act (SB 1120) de California prohíbe que la IA sea la base única de una denegación, retraso o modificación de la atención, tiene que revisarlo un clínico colegiado.
• El cuello de botella no es la velocidad del papeleo. Es que los criterios de las aseguradoras viven en PDFs no estructurados que cambian sin aviso, así que cada solicitud empieza releyendo las reglas a mano.
• La versión nativa en IA no saca a la persona de la decisión. Saca a la persona de reteclear los mismos datos clínicos en cinco formatos distintos.

¿De qué problema se hace cargo este sistema?

Un sistema de autorización previa se hace cargo del hueco entre una orden clínica y el reglamento de una aseguradora. Un médico decide que un paciente necesita una resonancia, un biológico o un procedimiento. La aseguradora ya ha publicado una lista de condiciones bajo las que cubrirá exactamente eso pero esa lista no está conectada con el historial, con la orden ni con el software del médico. Alguien tiene que leer los criterios de la aseguradora, leer el historial y escribir una carta que demuestre que el paciente cumple los criterios, en un formato que la aseguradora acepte.

Ese hueco no es tecnológico. Las aseguradoras publican criterios a propósito, para controlar el coste. El trabajo del sistema es cerrar la distancia entre «la regla existe» y «la regla se ha comprobado» sin cambiar quién está autorizado a tomar la decisión médica. Es el mismo problema de capa de coordinación que mapeé en cómo construiría un sistema de reservas de carga que oculta el transporte, información repartida entre partes que sostienen cada una una pieza.

El flujo existente que mapearía primero

Antes de diseñar nada, me sentaría una semana con el personal de autorizaciones de una clínica y registraría cada solicitud tal como ocurre de verdad, no como la describe la web de la aseguradora.

Cada paso de esa tabla es información que se mueve entre personas que sostienen cada una una pieza: el clínico tiene los hechos clínicos, la aseguradora tiene la regla, y el personal no tiene ninguna de las dos: son la capa de traducción. Esa capa de traducción es el problema de coordinación, no el papeleo.

Cómo funcionaría el sistema

La ruta nativa en IA no empieza por «automatizar el fax». Empieza por hacer que los criterios y el historial sean legibles para el mismo sistema al mismo tiempo.

Cuando un clínico emite una orden que históricamente activa una autorización previa, el sistema extrae los datos relevantes del historial (códigos diagnósticos, tratamientos previos probados, analíticas, imágenes) directamente de la historia clínica electrónica. En paralelo, resuelve el requisito actual de la aseguradora para ese código, bien mediante la API FHIR de autorización previa donde exista (obligatoria para buena parte de las aseguradoras a partir del 1 de enero de 2027 según CMS-0057-F), bien, hasta entonces, desde una base de conocimiento mantenida de políticas que se revisa de forma programada en lugar de en el momento de la necesidad.

El sistema redacta entonces la carta de necesidad médica como un mapeo estructurado: cada criterio que enumera la aseguradora, emparejado con la entrada concreta del historial que lo satisface. Donde un criterio no se cumple, lo dice en lugar de escribir alrededor. Ese borrador va al clínico prescriptor o a su delegado para revisión antes de que se envíe nada: esto no es «una persona pulsa aprobar sobre una caja negra», es alguien revisando una carta que muestra su razonamiento, criterio por criterio. Es el mismo límite de revisar-antes-de-enviar que usé en cómo rediseñaría la revisión de contratos como flujo nativo en IA: redacta con libertad, envía solo con firma.

Una vez aprobado el envío, el sistema presenta la solicitud por el canal que soporte la aseguradora y consulta el estado en lugar de que llame una persona. Solo devuelve el caso a un humano cuando hace falta una decisión: una petición de información, una denegación con su motivo declarado, o una aprobación. Ante una denegación, redacta el recurso del mismo modo: mapeado contra el motivo concreto dado, que la norma de 2026 ya obliga a declarar.

Nada de esto le quita una decisión a una persona. Le quita la obligación de releer un PDF de 30 páginas y reteclear los mismos tres valores analíticos en un cuarto formato este mes.

¿Qué queda bajo control humano?

Dos límites aquí no son decisiones de diseño: ya están escritos en ley y reglamento, y caen a ambos lados de la solicitud.

Del lado de la aseguradora, la Physicians Make Decisions Act de California modificó los códigos de salud y de seguros para establecer que la IA o una herramienta algorítmica no puede ser la base única para denegar, retrasar o modificar la cobertura por necesidad médica. Un médico colegiado o profesional sanitario cualificado con experiencia relevante tiene que revisarlo. Las aseguradoras también deben revelar cuándo usan IA en la revisión de utilización y someterse a auditorías periódicas. Otros estados están redactando textos similares, así que un sistema construido para esquivar este límite se apoya en un terreno que se está moviendo bajo sus pies, la misma línea de gobernanza que mapeé en cómo sería un flujo de cumplimiento nativo en IA.

Del lado de la clínica solicitante, el límite es responsabilidad profesional más que ley: lo que se envíe en nombre de un médico es una afirmación clínica de ese médico. Un sistema que redacta una carta y la envía sin revisión le está pidiendo a un clínico que se juegue su colegiación con un texto que nunca leyó. El paso redactar-y-luego-aprobar no es una casilla de cumplimiento: es la diferencia entre una herramienta que le ahorra tiempo a un clínico y otra que hace afirmaciones clínicas en su nombre sin que se entere.

Lo que queda para la automatización es real: extraer los campos correctos del historial, resolver qué política aplica, redactar el mapeo criterio por criterio, presentarlo por el canal correcto y perseguir el estado. Lo que no queda para la automatización es decidir que un paciente cumple un umbral clínico, o decidir que no lo cumple.

Cuándo es la construcción equivocada

Este sistema encaja mal con una aseguradora que no tiene ningún canal digital y realmente exige una llamada, forzar una herramienta con forma de API sobre una relación solo telefónica añade un paso de traducción en vez de quitarlo. También encaja mal en una consulta individual o clínica pequeña con un puñado de autorizaciones al mes; el coste continuo de mantener al día una base de criterios puede superar lo que ahorra un volumen bajo de solicitudes, lo que es un argumento a favor de un servicio compartido entre muchas consultas antes que de una construcción a medida para una, parecido al problema de arranque en frío que señalé en cómo construiría un sistema de siniestros de seguros nativo en IA.

Y es la construcción equivocada si el objetivo pasa en silencio a ser «reducir denegaciones» en lugar de «reducir trabajo de traducción». Un sistema afinado para escribir cartas más persuasivas no está cerrando el hueco de coordinación: está optimizando contra el proceso de revisión de la aseguradora, que es un proyecto distinto, más arriesgado y con otros incentivos.

Resumen

La autorización previa parece un problema de papeleo, y por eso la mayoría de los arreglos apuntan al fax. El cuello de botella real es que la regla de la aseguradora y el historial del paciente nunca han vivido en el mismo formato estructurado, así que una persona tiene que sostener ambos en la cabeza a la vez, dos veces si la solicitud se deniega. Una versión nativa en IA cierra ese hueco (casando historial con criterios, redactando la carta, siguiendo el estado) mientras deja la decisión de necesidad médica exactamente donde California y CMS dicen ahora que tiene que quedarse: con una persona colegiada que ha leído el caso.

Preguntas Frecuentes

¿Puede la IA denegar legalmente una solicitud de autorización previa? No. La Physicians Make Decisions Act (SB 1120) de California prohíbe a las aseguradoras usar IA o un algoritmo como base única para denegar, retrasar o modificar la atención por criterios de necesidad médica: un médico colegiado o profesional sanitario cualificado tiene que tomar la decisión final, y varios estados más están redactando normas similares.

¿Cuánto tiempo cuesta realmente la autorización previa a una consulta? La encuesta a médicos de la AMA de 2025 encontró que los médicos y su personal dedican una media de 13 horas semanales a autorizaciones previas y completan unas 40 solicitudes por semana, y el 94% dice que el proceso contribuye al desgaste profesional.

¿Qué exige la norma de autorización previa de CMS para 2026? Desde el 1 de enero de 2026, CMS-0057-F exige a las aseguradoras afectadas (Medicare Advantage, Medicaid y CHIP, y los planes de los mercados ACA) resolver las solicitudes urgentes en 72 horas y las ordinarias en 7 días naturales, y dar un motivo concreto para cada denegación.

¿Hará la API FHIR de autorización previa innecesario al personal de autorizaciones? No. La API, obligatoria desde el 1 de enero de 2027 para buena parte de las aseguradoras, estandariza cómo se mueven una solicitud y su resolución entre sistemas. Elimina un problema de transporte. Alguien sigue teniendo que reunir la evidencia clínica, juzgar si cumple los criterios y gestionar denegaciones y recursos.

¿Cuál es la parte más arriesgada de automatizar este flujo? Dejar que un sistema envíe una carta de justificación en nombre de un médico sin su revisión. El clínico prescriptor sigue siendo legal y profesionalmente responsable de lo que se envía, así que la aprobación para enviar sigue siendo un paso humano incluso después de que la IA redacte el contenido.