¿Qué es el lote XML TISS?
El lote XML TISS es el mensaje electrónico con el que el hospital presenta a la aseguradora el cobro de las atenciones, agrupando las guías en un solo archivo. TISS (Troca de Informações na Saúde Suplementar, intercambio de información en la salud suplementaria) es el estándar obligatorio de la ANS, la Agencia Nacional de Salud Suplementaria de Brasil, que regula los seguros de salud privados. Su Componente Organizacional define el cobro de guías como el mensaje del prestador a la aseguradora con un lote de cobro de los servicios realizados [3]. El mensaje LoteGuias cubre consultas, SP/SADT (servicios ambulatorios y estudios diagnósticos), resumen de hospitalización, honorarios y odontología [3].
El cobro es de implantación electrónica obligatoria en el estándar TISS (Troca de Informações na Saúde Suplementar) de la Agencia Nacional de Salud Suplementaria (ANS), y la Resolución Normativa (RN) 501/2022 exige el intercambio en la versión vigente (art. 7) [1]. Por eso el lote es el punto en que la facturación hospitalaria sale del hospital: todo lo que se revisó en la cuenta tiene que caber en una estructura que la aseguradora pueda leer.
Esta guía trata del sobre: el archivo, la transmisión y los rechazos que impiden el análisis. Las reglas de cada guía están en la guía Guías TISS.
Anatomía del lote: lo que el archivo debe contener
Un lote aceptado combina cuatro elementos, cada uno definido por un componente del estándar:
| Elemento | Qué es | Dónde se define |
|---|---|---|
| Estructura XML | Etiquetas, orden, tipos y longitudes de cada campo, en el namespace del esquema oficial | Componente de Comunicación: esquemas XSD y WSDL [3] |
| Encabezado del mensaje | Identifica la transacción (tipo, fecha y hora), remitente, destinatario y versión del estándar | Esquema del mensaje; rechazos en la tabla 38 [4] |
| Cuerpo del lote | Número de lote y las guías de cobro, con los códigos TUSS | Componente de Contenido y Estructura y TUSS [2] |
| Epílogo | El hash de la información del mensaje, para verificar la integridad | Componente Organizacional, ítem 148 [3] |
El estándar adopta el lenguaje XML y exige que todos los participantes usen, al generar los archivos, el namespace establecido en los esquemas XSD y en los descriptores WSDL [3]. Los archivos de definición están en el paquete del Componente de Comunicación, publicado en el sitio de la ANS. tissV4_03_00.xsd contiene la estructura principal de los mensajes, y el servicio web de envío de lote se describe en tissLoteGuiasV4_03_00.wsdl [3].
La aseguradora debe ofrecer a su red tanto servicios web como un portal, y el prestador elige el canal (ítems 129 y 130) [3]. El archivo es el mismo en los dos caminos; solo cambia la forma de entrega. La guía Interoperabilidad en salud: TISS, HL7 FHIR y el intercambio de datos con aseguradoras muestra dónde encaja el TISS entre los demás intercambios de datos.
¿Cómo funciona el hash del lote?
El hash es un código de verificación, grabado en el epílogo del mensaje, que permite a la aseguradora confirmar que el contenido recibido es igual al que se generó. Según el Componente Organizacional, se calcula sobre el contenido de las etiquetas concatenado, sin los nombres de elementos y atributos, siempre con codificación ISO-8859-1, y el resultado va en hexadecimal en el epílogo [3]. El mismo apartado exige que la contraseña del encabezado se envíe como hash MD5 [3].
En la práctica, esto tiene tres consecuencias:
- Editar el XML a mano invalida el lote. Abrir el archivo en un editor de texto y corregir un campo cambia el contenido, pero no el hash grabado. La aseguradora lo recalcula y no coincide.
- La codificación importa. Si el archivo se guarda en otra codificación después de generarlo, los caracteres acentuados pueden cambiar de bytes y el hash dejar de coincidir.
- La corrección siempre es en el origen. Lo seguro es corregir el dato en el sistema de facturación y generar el lote de nuevo.
Cuando el hash no coincide, el mensaje previsto en la tabla 38 es el 5014: “código hash inválido; el mensaje puede estar corrupto” [4].
Los rechazos de lote en la tabla 38
La tabla 38 de la TUSS reúne los mensajes que usan las aseguradoras en sus respuestas al prestador, y también mensajes del intercambio de datos entre aseguradora y ANS [3]. Por eso no todo código del grupo 5000 se aplica al lote del hospital. Los códigos siguientes describen rechazos de archivo, encabezado y totales, revisados en la versión 202607 de la TUSS, planilla oficial de la ANS [4]. Los textos están traducidos; el original en portugués está en la fuente.
| Capa | Código y texto de la tabla 38 [4] | Qué revisar |
|---|---|---|
| Estructura | 5001 — Mensaje electrónico fuera del estándar TISS | Que el archivo enviado sea de verdad el XML del lote, generado por el sistema |
| Estructura | 5002 — No fue posible validar el archivo XML | Validación contra el XSD de la versión: campo obligatorio ausente, tipo o longitud incorrectos, orden de etiquetas |
| Estructura | 5007 — Mensaje inconsistente o incompleto | Archivo truncado al generarse o al transmitirse |
| Versión | 5028 — Versión del estándar inválida | Versión declarada en el archivo frente a la versión que acepta la aseguradora |
| Integridad | 5014 — Código hash inválido. El mensaje puede estar corrupto | Edición manual, codificación distinta de ISO-8859-1 |
| Encabezado | 3148 — Tipo de transacción inválido | Tipo de transacción compatible con el mensaje de envío de lote |
| Encabezado | 5025 y 5026 — Fecha y hora de registro de la transacción inválidas | Formato y coherencia de la fecha y la hora de la transacción |
| Encabezado | 5005 — Remitente no identificado · 1206 — CPF / CNPJ inválido | Código del prestador en la aseguradora, CNPJ (registro fiscal de empresas en Brasil) |
| Encabezado | 5006 — Destinatario no identificado · 5027 — Registro ANS de la aseguradora inválido | Registro ANS de la aseguradora de destino |
| Cuerpo | 5047 — Número de lote no informado | Número de lote completo |
| Cuerpo | 5015 — Número de guías/estados dentro del mensaje superior al tamaño máximo permitido | Cantidad de guías por lote, dentro del límite del esquema y del manual de cada aseguradora |
| Totales | 1104 — Valor total del protocolo distinto del valor total de las guías | Suma de guías y de valores del lote |
| Contenido | 1308 — Guía ya presentada | Guía reenviada en un lote nuevo |
| Plazo | 3161 — Plazo de envío fuera del periodo contractual acordado entre las partes | Fecha de envío y plazo del contrato |
Los rechazos de contenido clínico y de precio, que afectan ítems dentro de guías analizadas, quedan fuera de esta lista. Están en la guía Códigos de glosa TISS, donde se explica la glosa (rechazo de pago, total o parcial).
Tres capas de validación antes del envío
La validación del lote es más simple cuando se organiza en tres capas, que siguen los grupos de rechazos de la tabla anterior. Revisar una capa solo vale la pena cuando la anterior ya pasó.
- Estructura. El archivo se valida contra el XSD de la versión vigente. Aquí caen el archivo equivocado, los campos obligatorios ausentes, tipos y longitudes fuera del esquema y la versión del estándar no aceptada.
- Integridad. Se recalcula el hash del epílogo y se revisan los totales del lote contra la suma de las guías.
- Reglas de negocio. La aseguradora revisa remitente, destinatario, número de lote, guías ya presentadas y plazo de envío, además de las reglas del contrato.
La validación contra el XSD puede hacerse en el propio hospital, antes del envío, con los esquemas oficiales que publica la ANS [3]. La segunda capa depende de que el sistema genere el hash al final y de que nadie edite el archivo después. La tercera exige un registro correcto del prestador y de la aseguradora y el control de las guías ya enviadas.
Por qué la versión del estándar rechaza el lote completo
El rechazo por versión (5028) devuelve el lote completo porque la aseguradora valida el archivo contra el esquema de la versión que acepta. La RN 501/2022 exige el intercambio en la versión vigente [1], y cada componente del estándar tiene su propia versión. En septiembre de 2026 eran estas [2]:
| Componente | Versión vigente (sep/2026) | Qué cambia en el lote |
|---|---|---|
| Organizacional | 202609 | Reglas de envío, protocolo, hash |
| Contenido y Estructura | 202511 | Campos y estructura de las guías |
| TUSS (terminología) | 202607 | Códigos que entran en las guías |
| Seguridad y Privacidad | 202511 | Requisitos de confidencialidad y certificado |
| Comunicación | 04.03.00 y 01.06.00 | Esquemas XSD y WSDL que debe seguir el archivo |
La versión del esquema (04.03.00) aparece en el nombre de los archivos XSD y WSDL. La ANS publica el estándar en paquetes con fecha, y el cuadro de versiones vigentes debe revisarse en la página del estándar TISS con cada nueva publicación. El detalle de cada componente está en la guía Estándar TISS.
Estar en la versión vigente también tiene efectos contractuales. Según la RN 503/2022, las prohibiciones que garantizan al prestador el acceso a las justificaciones de glosa y el derecho a impugnarla solo se aplican cuando la facturación se hace en el estándar TISS vigente (art. 5, párrafo único) [5]. Y uno de los requisitos del nivel C del Factor de Calidad de la ANS (Fator de Qualidade, que modula el ajuste de los contratos de hospitales) es tener al menos 75% de las guías en el TISS vigente [6].
Protocolo de recepción: qué comprueba y qué no
El protocolo es el número que emite la aseguradora al recibir el lote y es la comprobación de recepción que prevé el estándar para lotes de guías, lotes de anexos y apelaciones de glosa [3]. Viene acompañado de la lista de números de guía enviados por el prestador y, cuando aplica, de los números asignados por la aseguradora [3].
El protocolo no significa que las guías fueron aceptadas. Después de él, el estándar prevé la solicitud de estatus del protocolo y la respuesta con la situación de todas las guías, además de la solicitud de cancelación de un lote, guía o apelación ya enviados [3]. El análisis llega en el estado de análisis de cuenta (demonstrativo de análise de conta), tema de la guía Estado de análisis de cuenta y de pago.
De ahí salen dos reglas prácticas:
- Guardar juntos protocolo y archivo. El número de protocolo, el XML enviado y la fecha son la prueba de entrega en plazo.
- Cancelar antes de volver a presentar. Reenviar una guía que ya está en otro protocolo puede generar el rechazo 1308 (guía ya presentada) [4]. El estándar prevé un mensaje de cancelación de guía o lote para este caso [3].
Lo que vemos en la operación
En Accrua, la validación del lote XML es una de las etapas que los agentes de Accrua OS ejecutan solos, porque tiene regla definida: schema de la versión vigente, estructura, hash y campos obligatorios. El lote se revisa antes del envío, y se da seguimiento al protocolo de recepción hasta que llega.
Separamos los dos tipos de problema que distingue la guía. El rechazo de archivo, como XML fuera del estándar TISS, hash inválido o versión equivocada, devuelve el lote completo y retrasa el protocolo. La glosa de contenido llega después, en el reporte de pago, guía por guía. Accrua OS concilia ese reporte y vincula cada glosa con el concepto y con la regla de la aseguradora.
Como el hash deja de coincidir cuando un campo cambia después de generado, corregimos el dato en el origen y generamos el lote de nuevo, en lugar de editar el archivo. Cuando una aseguradora cambia de versión del estándar, su regla de validación se ajusta antes del siguiente envío.
Por dónde empezar
- Valide cada lote contra el XSD oficial de la versión vigente antes del envío, con los esquemas del Componente de Comunicación que publica la ANS.
- Prohíba editar el XML a mano. Toda corrección regresa al sistema de facturación, y el lote se genera de nuevo, con hash nuevo.
- Registre cada rechazo por código y por aseguradora, separando archivo (5001, 5002, 5014, 5028) de encabezado, totales y guía.
- Archive protocolo, archivo y fecha de cada lote, y controle las guías por protocolo para no volver a presentarlas sin cancelar.
- Siga el cuadro de versiones en la página del estándar TISS de la ANS y confirme con cada aseguradora la fecha de corte de la versión anterior.