What is the TISS standard?
The TISS standard is the set of rules, data structures, codes and security requirements that ANS makes mandatory for the electronic exchange of information about care delivered to health plan members. In Brazil's private health system, health plans are called operadoras. RN 501/2022 sets up the standard and defines its purposes. It standardizes eligibility checks, requests, authorizations, billing, payment statements and appeals of denials (claim denials, full or partial). It also feeds ANS's oversight of health plans [1].
In practice, TISS is the “common language” of hospital billing in Brazil. A health plan (operadora) only processes a claim that arrives in the format, with the codes and in the version the standard requires. A standard error therefore becomes a rejected batch or a denial before anyone looks at the clinical content of the claim.
RN 501/2022 requires the exchange to be electronic and on the current version (art. 7) [1]. The standard covers exchanges among health plans, providers, contracting employers, members and ANS. It does not cover reimbursement requests that members send to their health plan [1].
For US readers, the closest equivalent is the set of HIPAA transaction standards (X12 5010) plus FHIR-based APIs. The difference is scope: TISS is one standard, run by one agency, and it includes its own code terminology.
The five components and what each one defines
The TISS standard has five components. Each one is updated and versioned on its own [2]. So there is no single “TISS version”. There is a combination of the current versions of all five.
| Component | What it defines | Current version (Sep 2026) [2] | Impact on billing |
|---|---|---|---|
| Organizational | Operating rules: what is mandatory, who sends what, implementation deadlines, prohibitions | 202609 | Defines what a health plan can and cannot demand |
| Content and Structure | Data architecture of claim forms, electronic messages and the contingency plan | 202511 | Changes XML fields and validations |
| Health Concept Representation (TUSS) | The unified terminology (Terminologia Unificada da Saúde Suplementar): procedures, supplies, drugs, daily rates, denial messages | 202609 | Changes the codes on the claim |
| Security and Privacy | Requirements for data secrecy, privacy and confidentiality | 202511 | Digital certificate, access control |
| Communication | Transmission means and methods; uses XML | 04.03.00 and 01.06.00 | Schema version the system must read and generate |
TUSS, the terminology component, changes the most. The September 2026 version added 21,234 terms to table 19 (supplies and implants, known as OPME), 781 to table 20 (drugs) and 2 to table 22 (procedures and health events). It also deactivated 2 terms in table 22 [3]. Since July 2026, ANS has run a TUSS lookup platform, with downloads in Excel, CSV and JSON and API access [5]. Codes and tables are covered in the guide TUSS code table. The standard is central to hospital billing and to interoperability between hospitals and health plans.
What must be electronic?
Not every exchange in the standard has to be electronic. The Organizational Component sets three groups [3]:
| Situation | Processes | What it means in practice |
|---|---|---|
| Mandatory electronic implementation | Billing for services; authorization attachment batch; admission or discharge notice; return statements (payment and claim review); denial appeal | The hospital must send, and the health plan must receive and respond, in XML under the standard |
| Optional electronic implementation | Eligibility verification; procedure authorization (except the attachment batch); sending and receiving documents | Neither side can force electronic exchange on the other; if a health plan adopts it, it must follow the standard |
| Paper exchange, per contract | In-person attendance receipt; proof of care for the dental treatment form | The contract governs |
For hospitals, the key point is that denial appeals and statements are in the mandatory group. The hospital gets a structured return for each claim form (guia), with the reason for each denial coded in TUSS table 38. It also sends the appeal (recurso de glosa) through the same channel. The step-by-step process is in the guide Denial appeals.
What a health plan cannot demand
The Organizational Component includes prohibitions that protect providers [3]:
- Changing the standard. A health plan cannot change the TISS standard or create its own version.
- Asking for paper copies of electronic exchanges. If the message was signed with an ICP-Brasil digital certificate (Brazil's public key infrastructure), the health plan cannot require a paper copy. The certificate must be the e-CNPJ of the institution that sends the message, or the e-CPF when the provider works as an individual.
- Requiring ICD codes on TISS claim forms. Following a court decision, the component forbids health plans from requiring, under any circumstances, the CID (Classificação Internacional de Doenças, Brazil's name for the ICD) on TISS claim forms.
- Keeping its own table after the deadline. Once the implementation deadline for a TUSS term has passed, the health plan cannot use its own code for the same item.
When a demand outside the standard comes up, record it and take it to contract negotiation. Under RN 503/2022 (ANS Normative Resolution 503/2022), the contract must spell out billing and audit routines. Keeping TISS current also protects the hospital under the contract: the bans that guarantee access to denial justifications and the right to dispute apply only if billing follows the current TISS standard (art. 5, sole paragraph) [4]. The guide RN 503/2022: what the payer contract must say covers this point.
How the TISS standard works day to day
The standard follows care from start to finish. The flow below shows the main exchanges between hospital and health plan [3]:
- Eligibility (optional in electronic form). The hospital checks that the member is active and what the plan covers. If the answer is negative, the health plan must state the reason (item 45). The checklist is in the guide Eligibility verification.
- Request and authorization. The hospital requests authorization on the matching claim form (SP/SADT, admission request, extension) and sends attachments (OPME, chemotherapy, radiotherapy). The health plan responds with an authorization number (senha) or a denial. The reply must list every item requested, including those not authorized (item 46.3). Denying, conditioning or delaying care on the grounds that a TUSS code or a proprietary table is missing violates ANS rules (item 117).
- Admission and discharge notice (mandatory). The hospital reports the admission and the discharge.
- Batch billing (mandatory). Billing forms (consultation, SP/SADT, inpatient summary, professional fees) and the other-expenses attachment are grouped into a batch (lote) and sent in XML. Health plans must offer both web services and a portal for this exchange, and the provider chooses which to use (items 129 and 130). The health plan returns a protocol number as proof of receipt. The same applies to the attachment batch and to the denial appeal.
- Return statements (mandatory). The health plan sends the claim review statement (demonstrativo de análise de conta), with the status and denials for each claim form in the batch, and the payment statement. How to read and reconcile both is in the guide Claim review and payment statements.
- Denial appeal (mandatory). The hospital contests denials through the appeal message and receives a protocol number. It can check the status. The health plan responds by accepting the appeal, rejecting it or reporting a new review.
Each claim form has its own rules for filling it in and for linking it to other forms. The details are in the guide TISS claim forms. The codes for each denial reason are in the guide TISS denial codes.
How to track versions without rejected batches
A version the health plan does not accept sends the whole batch back (TUSS table 38, code 5028, invalid standard version) [6]. The file the system generates stops passing the health plan's validation. Each new TUSS term has an implementation deadline of at least three months after it takes effect [3]. Health plans usually announce the date from which they will reject files in older versions.
| Routine | Frequency | Owner |
|---|---|---|
| Check the current versions table on the ANS TISS standard page | Monthly and with every ANS notice | Billing coordination |
| Read the change log of each new version and list what affects the hospital (tables 19, 20, 22, 38) | Every new version | Billing and IT |
| Confirm the update date with the system vendor | Every new version | IT |
| Update the price table and item master with new or deactivated codes | Before the implementation deadline | Billing and supply chain |
| Validate the XML before sending and track the batch rejection rate | Every batch | Billing |
| Log health plan notices about cutoff dates for old versions | Ongoing | Billing |
The batch rejections listed in TUSS table 38 and how to avoid them are in the guide TISS XML batches: submission errors. The batch rejection rate is one of the revenue cycle indicators.
What we see in operations
At Accrua, TISS validation is the agents' job. Before each submission, the XML is checked against the current version of every component, against the TUSS terminology and against what that health plan's contract defines. Submission, the batch receipt and status tracking also run automatically, because they follow a defined rule.
Accrua OS runs on top of the HIS/ERP the hospital already uses, so nothing is retyped to fit the standard. When a health plan asks for something outside the standard, the case is logged with its source and goes to a person, who decides how to respond based on the rules this guide describes.
We also follow TUSS updates, especially the tables for supplies, drugs and OPME (implants and devices). When a new version changes codes, we review the hospital's item master before the first batch comes back rejected, and every change is recorded in an audit trail.
Where to start
- Identify the versions in use in the hospital's system and compare them with the ANS current versions table.
- Name an owner to track standard releases and health plan notices.
- Measure the batch rejection rate by health plan and by reason, every week.
- List the demands outside the standard from each health plan and take them to contract negotiation.
- Validate the XML before sending with the rules of the current version.