Healthcare interoperability: TISS, HL7 FHIR and data exchange with payers

What is healthcare interoperability?

Interoperability is the ability of two systems to exchange information without rework, with the receiving system understanding the data exactly as the sending system meant it. In practice there are two layers: the technical layer (format and transport, such as XML or FHIR) and the semantic layer (the meaning of the codes, such as TUSS terms).

In hospital billing, interoperability is what lets a claim leave the hospital's system and enter the health plan's system without being retyped. When it fails, it shows up as a rejected batch, an unrecognized code or a request for paper documents. Choosing the systems and partners that bridge this gap is covered in the pillar guide Hospital billing outsourcing.

The TISS standard: mandatory administrative interoperability

The TISS standard (Troca de Informações na Saúde Suplementar, “information exchange in supplementary health”) is the ANS's mandatory standard for electronic exchange of care data among health plans, providers and the ANS. RN 501/2022 requires the exchange to be electronic and on the current version (art. 7) ^[1].

The standard has five components, each with its own version. In September 2026, the Organizational component and TUSS were at version 202609; Content and Structure and Security and Privacy at 202511; and Communication at versions 04.03.00 and 01.06.00 ^[2]. Each component is covered in the TISS standard guide.

On the technical side, the Organizational Component establishes that ^[3]:

• the health plan offers a web service and a portal, and the provider chooses which to use (items 129 to 133);
• messages follow the tissV4_03_00.xsd XML schema, with a mandatory namespace (items 134 and 139);
• digital signatures use XAdES with an ICP-Brasil certificate, Brazil's public key infrastructure (items 143 to 146);
• billing, attachment batches, admission and discharge notices, remittance statements and denial appeals must be electronic (item 33); eligibility and authorization (except attachments) are optional in electronic form (item 34).

In other words, TISS already is interoperability, but administrative in nature. It carries what was done and what it costs, with little structured clinical data. The clinical justification for an extended stay or a special device usually goes as free text or an attachment. The fields of each form are covered in the TISS claim forms guide, and file-level rejections in the TISS XML errors guide.

What role does TUSS play, and where does FHIR already appear?

TUSS (Terminologia Unificada da Saúde Suplementar, the unified terminology of supplementary health) is the TISS component that represents concepts: the code tables for procedures, supplies, drugs, daily rates and denial messages ^[3]. It ensures that “adult ICU daily rate” has the same code for the hospital and the health plan.

The ANS offers TUSS lookups on a platform built on Open Concept Lab (OCL), with downloads in Excel, CSV and JSON and API access ^[4]. For billing teams, this makes it easier to keep the item master and price table in sync with current codes. How the tables are used is covered in the TUSS code table guide.

Some TUSS tables are also published as FHIR resources (CodeSystem) in the ANS implementation guide, but at version 202309, earlier than the current one ^[5]. For day-to-day code lookups, the reference is the OCL platform and the current standard published by the ANS, not the FHIR test version.

HL7 FHIR: the technical standard for clinical data exchange

HL7 FHIR (Fast Healthcare Interoperability Resources) is a standard from HL7 International for exchanging health data. It organizes information into “resources” (patient, encounter, observation, medication and others) exchanged through web APIs, in JSON or XML. The Brazilian initiatives cited in this guide use version R4 (4.0.1) ^[5].

The practical difference from TISS XML is granularity. Instead of a closed document shaped like a claim form, FHIR lets systems exchange pieces of structured clinical information (a lab result, a coded diagnosis, a discharge summary) that other systems can read and reuse.

The ANS FHIR initiative. The ANS published the Implementation Guide for the Standardization and Qualification of Supplementary Health Care Data Project (PQDAS), package br.gov.ans.fhir version 202309, based on FHIR R4 ^[5]. According to the guide itself:

• it is a proof of concept;
• its defined scope is converting, from XML to FHIR, the health-plan-to-ANS message of the TISS Content and Structure Component;
• profiles were modeled openly so other exchange processes can be added later.

The guide does not say FHIR replaces TISS XML, and it sets no timeline. Until then, exchange between hospitals and health plans stays in XML, on the current TISS version.

What is the RNDS, Brazil's National Health Data Network?

The RNDS (Rede Nacional de Dados em Saúde) is the Ministry of Health's national health data integration platform. Ordinance 1,434 of May 28, 2020 created the Conecte SUS program and the RNDS and adopted health interoperability standards, amending Consolidation Ordinance 1/2017 ^[6]. The RNDS technical guide states that integration follows the FHIR standard and that a connected facility can contribute its patients' data and consume data recorded by other facilities ^[7].

The RNDS started with COVID-19 test results, which laboratories were required to report (Ordinance 1,792/2020) ^[6][7]. Information models published by ordinance followed, including ^[6]:

• medication prescription and dispensing (SAES/MS Ordinance 50/2022);
• the Clinical Encounter Record, or RAC (Ordinance 234/2022);
• care regulation (SAES/SEIDIGI Joint Ordinance 3/2023);
• the Discharge Summary and Obstetric Discharge Summary (GM/MS Ordinances 8,026 and 8,025, of 08/27/2025).

The National Health Information and Informatics Policy, as worded by GM/MS Ordinance 1,768/2021, provides that health facilities send care records to the RNDS (art. 18, II) and that the Ministry of Health regulate national interoperability standards ^[8]. How far that duty reaches for each private hospital depends on the ordinances for each use case.

TISS, FHIR and RNDS side by side

What changes for billing

Structured clinical data exchange is not, today, a requirement in the hospital-health plan relationship. But the direction of the standards shows where billing can gain:

• Less manual entry. When the hospital management system builds the claim from the encounter record, rather than from a biller retyping it, field and code errors that trigger batch rejections drop.
• Better-supported authorization. Structured clinical data (coded diagnosis, lab results, progress notes) can go with the request in machine-readable form, which reduces requests for more information. Today that justification goes as free text or an attachment.
• Audit on a shared basis. If hospital and health plan read the same clinical data, disputes over length of stay, supplies or procedures start from a common basis instead of copies of the medical record.
• RNDS integration. Hospitals that already send the Discharge Summary or the RAC to the RNDS have structured clinical data at the source, reusable in other workflows.

None of this replaces TISS. Billing must still be electronic, in XML, on the current version ^[1][3]. The caution is not to buy promises of “FHIR integration with health plans” without asking which plan, which message and under which rule. When choosing a system, require support for current TISS versions, TUSS updates and the ability to produce and consume FHIR R4 (see the Hospital management systems guide). Bots that copy data between portals solve part of the problem while native integration does not exist; the Hospital billing automation (RPA) guide discusses where to start.

LGPD: health data is sensitive data

Every data exchange with a health plan, with the RNDS or with outsourced providers involves sensitive personal data, as Law 13,709/2018 (LGPD) classifies health data (art. 5, II) ^[9]. Processing requires a legal basis under art. 11, and the law requires security measures (art. 46) and incident reporting to the ANPD, the data protection authority, and to the data subject (art. 48) ^[9]. In TISS, this adds to the Security and Privacy Component and the ICP-Brasil signature ^[3]. Hospitals that outsource billing need the contract to define controller and processor roles. The topic has its own guide: LGPD in hospital billing.

What we see in operations

Accrua works on top of the HIS/ERP the hospital already uses: Accrua OS reads the claim in the hospital's system, with no system replacement and no re-keying. In practice, this is interoperability applied to billing: data is entered once and goes to the health plan in the format it requires.

The TISS standard remains the language of the exchange with health plans. Agents validate the XML in the current version before submission, so version or schema errors are caught before the batch goes out, and they track status and remittance statements through reconciliation. Clinical data from the medical record and prescriptions feeds the pre-submission claim check and the appeal, when the health plan asks for justification.

Health data is sensitive personal data. In the relationship with Accrua, the hospital is the controller and Accrua is the processor under the LGPD (Brazil's General Data Protection Law), and hospital and patient data do not train models from Accrua or third parties. Every action, by an agent or a person, stays in an audit trail.

Where to start

1. Map the data flows with each health plan: what goes by web service, what goes by portal and what is still typed by hand.
2. Check the TISS and TUSS versions in your system against the current ANS table.
3. Ask your system vendor about FHIR R4 support and RNDS integration, with a roadmap and cases already in production.
4. Structure clinical data at the source (diagnosis, progress notes, discharge summary), because it supports authorization and appeals.
5. Review contracts and data flows under the LGPD, including third parties that access claim data.