Hoy, en muchas instituciones, la atención se registra en el sistema propio y después alguien la vuelve a digitar en la plataforma del SIS. Es doble trabajo, y cada tipeo es una oportunidad de rechazo.
El FUA —Formato Único de Atención— es el documento con el que un establecimiento le informa al SIS qué atención recibió un asegurado: quién es el paciente, qué se le hizo, qué diagnósticos, qué prestaciones. De ese registro depende, en buena parte, el financiamiento de la atención.
Dónde nace el problema
El dato de la atención ya existe. Está en el sistema del hospital, en el HIS, porque ahí se registró la consulta, el diagnóstico, los procedimientos. El problema es que ese mismo dato se vuelve a escribir a mano en la plataforma del SIS.
Escribir dos veces lo mismo tiene un costo garantizado: lo que se digitó bien en un lado se digita mal en el otro. Y en el FUA, un error no es un detalle estético: es un rechazo.
Por qué se rechazan los envíos
Los motivos se repiten. Vale la pena conocerlos porque casi todos se pueden evitar antes de enviar:
- Datos incompletos. Falta un campo obligatorio, un diagnóstico sin código, una prestación sin su dato asociado. El formato no está completo y no pasa.
- Afiliación no vigente. El paciente no estaba afiliado, o su afiliación no cubría la fecha de la atención. Esto no lo arregla revisar el FUA: hay que verificarlo antes de atender o antes de enviar.
- Códigos mal puestos. Diagnósticos, procedimientos y prestaciones se informan con códigos. Un código que no existe, que no corresponde o que no es coherente con el resto tumba el envío.
Casi ningún rechazo es una sorpresa. Es un dato que se pudo revisar antes y no se revisó, porque revisar a mano cientos de FUAs no lo hace nadie.
La idea: enviar, no volver a escribir
Si el dato de la atención ya está en el HIS, no tiene sentido copiarlo. Tiene sentido que el propio sistema lo arme y lo envíe.
El SIS ofrece una vía para eso: el SETI-SIS recibe los FUAs por API. Es decir, el sistema del hospital puede mandar la atención de forma electrónica, sin que nadie la vuelva a digitar en una pantalla aparte.
El flujo cambia de forma:
- La atención se registra una sola vez, donde siempre: en el HIS.
- El sistema arma el FUA con esos datos.
- Antes de enviar, valida.
- Envía al SETI-SIS por API y guarda la respuesta.
Validar antes de enviar es lo que ahorra
La parte que más rechazos evita es la validación previa. Si el sistema revisa el FUA antes de mandarlo, los problemas se atajan cuando todavía se pueden corregir sin costo.
Validar antes significa comprobar cosas concretas: que estén todos los campos obligatorios, que la afiliación esté vigente para la fecha de atención, que cada código exista y sea coherente con los demás. Lo que hoy se descubre cuando el SIS rechaza, se puede descubrir un minuto después de registrar la atención.
La diferencia es de momento. Un dato mal puesto que se detecta al validar se corrige en segundos. El mismo dato que llega hasta el SIS vuelve como rechazo, entra en una cola de reprocesos y se arregla días después, cuando ya nadie recuerda el detalle.
Lo que se gana
El beneficio no es abstracto:
- Menos rechazos, porque los errores se atajan antes de enviar y no después.
- Menos reprocesos, porque no hay una segunda digitación que corregir ni una cola de FUAs devueltos que rehacer.
- Menos trabajo manual, porque la persona que hoy copia datos de una pantalla a otra deja de hacerlo.
Y hay un efecto de fondo: el dato que informa el establecimiento es el mismo que registró, no una copia hecha a mano. Eso hace que lo que se envía al SIS refleje de verdad lo que pasó en la atención.
Cuando el FUA sale del mismo sistema donde se registró la atención —validado antes de enviar y por API—, la doble digitación deja de existir y el rechazo deja de ser lo normal.