What is a TISS XML batch?
A TISS XML batch is the electronic message a hospital uses to bill a health plan, grouping claim forms in a single file. TISS (Troca de Informações na Saúde Suplementar, or Information Exchange in Supplementary Health) is the mandatory data exchange standard set by ANS, Brazil's National Agency for Supplementary Health, the regulator of private health plans. Its Organizational Component defines claim billing as the provider-to-health-plan message carrying a billing batch of services performed [3]. The LoteGuias message covers office visits, SP/SADT (outpatient services and diagnostic tests), inpatient summaries, professional fees and dental care [3].
Billing is a mandatory electronic exchange under TISS (Troca de Informações na Saúde Suplementar), the data exchange standard of Brazil's National Supplementary Health Agency (ANS), and Normative Resolution (RN) 501/2022 requires the exchange to use the current version (art. 7) [1]. That makes the batch the point where hospital billing leaves the hospital: everything checked on the claim has to fit a structure the health plan can read. In US terms, it plays a role similar to an 837 claim file, but with Brazil-specific rules.
This guide covers the envelope: the file, the transmission and the rejections that block review. The rules for each claim form are in the TISS claim forms guide.
Batch anatomy: what the file must contain
An accepted batch combines four elements, each defined by a component of the standard:
| Element | What it is | Where it is defined |
|---|---|---|
| XML structure | Tags, order, types and lengths of each field, in the official schema namespace | Communication Component: XSD and WSDL schemas [3] |
| Message header | Identifies the transaction (type, date and time), sender, recipient and standard version | Message schema; rejections in table 38 [4] |
| Batch body | Batch number and the billing claim forms, with TUSS codes | Content and Structure Component and TUSS [2] |
| Epilogue | The hash of the message content, used to check integrity | Organizational Component, item 148 [3] |
The standard uses XML and requires every party to use the namespace set in the XSD schemas and WSDL descriptors when generating files [3]. The definition files are in the Communication Component package on the ANS website. tissV4_03_00.xsd holds the main message structure, and the batch submission web service is described in tissLoteGuiasV4_03_00.wsdl [3].
Health plans must offer their network both web services and a portal, and the provider chooses the channel (items 129 and 130) [3]. The file is the same either way; only the delivery method changes. The guide Healthcare interoperability: TISS, HL7 FHIR and data exchange with payers shows where TISS fits among other data exchanges.
How does the batch hash work?
The hash is a check code, written in the message epilogue, that lets the health plan confirm the content received matches what was generated. Under the Organizational Component, it is computed over the concatenated tag contents, without element and attribute names, always in ISO-8859-1 encoding, and the result goes in hexadecimal in the epilogue [3]. The same section requires the header password to be sent as an MD5 hash [3].
In practice, this has three consequences:
- Hand-editing the XML invalidates the batch. Opening the file in a text editor and fixing a field changes the content but not the stored hash. The health plan recalculates it, and it does not match.
- Encoding matters. If the file is saved in another encoding after it is generated, accented characters may change bytes and the hash may no longer match.
- The fix always happens at the source. The safe path is to correct the data in the billing system and generate the batch again.
When the hash does not match, the table 38 message is 5014: “invalid hash code; message may be corrupted” [4].
Batch rejections in table 38
TUSS table 38 lists the messages health plans use in responses to providers, as well as messages for data exchange between health plans and ANS [3]. That is why not every 5000-series code applies to a hospital batch. The codes below describe file, header and totals rejections, checked in TUSS version 202607, the official ANS spreadsheet [4]. Texts are translated; the original Portuguese wording is in the source.
| Layer | Table 38 code and text [4] | What to check |
|---|---|---|
| Structure | 5001 — Electronic message outside the TISS standard | Whether the uploaded file is really the batch XML generated by the system |
| Structure | 5002 — The XML file could not be validated | Validation against the version's XSD: missing required field, wrong type or length, tag order |
| Structure | 5007 — Inconsistent or incomplete message | File truncated during generation or transmission |
| Version | 5028 — Invalid standard version | Version declared in the file vs. version the health plan accepts |
| Integrity | 5014 — Invalid hash code. Message may be corrupted | Hand edits, encoding other than ISO-8859-1 |
| Header | 3148 — Invalid transaction type | Transaction type matches the batch submission message |
| Header | 5025 and 5026 — Invalid transaction date and time | Format and consistency of the transaction date and time |
| Header | 5005 — Sender not identified · 1206 — Invalid CPF / CNPJ | Provider code at the health plan, CNPJ (Brazilian company tax ID) |
| Header | 5006 — Recipient not identified · 5027 — Invalid health plan ANS registration | ANS registration number of the receiving health plan |
| Body | 5047 — Batch number not provided | Batch number filled in |
| Body | 5015 — Number of claim forms/statements in the message exceeds the maximum allowed | Claim forms per batch, within the limit set by the schema and each health plan's manual |
| Totals | 1104 — Protocol total differs from the claim forms total | Sum of claim forms and amounts in the batch |
| Content | 1308 — Claim form already submitted | Claim form resent in a new batch |
| Deadline | 3161 — Submission outside the contractual period agreed by the parties | Submission date and contract deadline |
Clinical and pricing rejections, which hit items inside reviewed claims, are not on this list. They are in the TISS denial codes guide, where denial (claim denial, full or partial) is explained.
Three validation layers before submission
Batch validation is simpler when it is organized in three layers, following the rejection groups in the table above. Checking a layer only pays off once the previous one passes.
- Structure. The file is validated against the XSD of the current version. This catches the wrong file, missing required fields, types and lengths outside the schema and an unaccepted standard version.
- Integrity. The epilogue hash is recalculated and batch totals are checked against the sum of the claim forms.
- Business rules. The health plan checks sender, recipient, batch number, claim forms already submitted and the submission deadline, plus contract rules.
XSD validation can be done in the hospital before sending, with the official schemas published by ANS [3]. The second layer depends on the system generating the hash last and nobody editing the file afterward. The third requires correct provider and health plan records and tracking of claims already sent.
Why the standard version rejects the whole batch
The version rejection (5028) returns the whole batch because the health plan validates the file against the schema of the version it accepts. RN 501/2022 requires exchange in the current version [1], and each component of the standard has its own version. In September 2026 they were [2]:
| Component | Current version (Sep 2026) | What it changes in the batch |
|---|---|---|
| Organizational | 202609 | Submission rules, protocol, hash |
| Content and Structure | 202511 | Fields and structure of claim forms |
| TUSS (terminology) | 202607 | Codes on the claim forms |
| Security and Privacy | 202511 | Confidentiality and certificate requirements |
| Communication | 04.03.00 and 01.06.00 | XSD and WSDL schemas the file must follow |
The schema version (04.03.00) appears in the XSD and WSDL file names. ANS publishes the standard in dated packages, and the table of current versions should be checked on the TISS standard page at each new release. Each component is covered in the TISS standard guide.
Staying on the current version also has contractual effects. Under RN 503/2022, the prohibitions that guarantee providers access to the reasons for each denial and the right to contest it only apply when billing uses the current TISS standard (art. 5, sole paragraph) [5]. And one of the level C requirements of the ANS Quality Factor (Fator de Qualidade, a multiplier on hospital contract adjustments) is having at least 75% of claim forms on the current TISS version [6].
Receipt protocol: what it proves and what it does not
The protocol is the number the health plan issues on receiving a batch. It is the proof of receipt the standard sets for claim batches, attachment batches and denial appeals [3]. It comes with the list of claim form numbers sent by the provider and, where applicable, the numbers assigned by the health plan [3].
The protocol does not mean the claims were accepted. After it, the standard provides for a protocol status request and a response with the status of every claim form, plus a request to cancel a batch, claim form or appeal already sent [3]. The review comes in the claim review statement (demonstrativo de análise de conta), covered in the Claim review and payment statements guide.
Two practical rules follow:
- Keep the protocol and the file together. The protocol number, the XML sent and the date are the proof of on-time submission.
- Cancel before resubmitting. Resending a claim form that is already under another protocol can trigger rejection 1308 (claim form already submitted) [4]. The standard provides a cancellation message for claim forms or batches for this case [3].
What we see in our operations
At Accrua, XML batch validation is one of the steps that Accrua OS agents carry out on their own, because it has a defined rule: the schema for the current version, structure, hash and required fields. The batch is checked before submission, and the receipt protocol is tracked until it arrives.
We separate the two kinds of problem this guide distinguishes. A file-level rejection, such as XML outside the TISS standard, an invalid hash or the wrong version, sends the whole batch back and delays the protocol. Content denials come later, in the remittance statement, form by form. Accrua OS reconciles that statement and ties each denial to the item and to the health plan's rule.
Because the hash stops matching when a field changes after the file is generated, we fix the data at the source and generate the batch again instead of editing the file. When a health plan moves to a new version of the standard, its validation rule is updated before the next submission.
Where to start
- Validate every batch against the official XSD of the current version before sending, using the Communication Component schemas published by ANS.
- Forbid hand-editing the XML. Every fix goes back to the billing system, and the batch is regenerated with a new hash.
- Log each rejection by code and health plan, separating file (5001, 5002, 5014, 5028) from header, totals and claim form.
- Archive the protocol, file and date of each batch, and track claim forms by protocol so nothing is resubmitted without cancellation.
- Track the version table on the ANS TISS standard page and confirm with each health plan the cutoff date for the previous version.