AI in Tasy: auditing hospital bills before billing, with fewer denials

AI in Tasy for claims audit means reviewing every patient bill before it closes and goes to billing, not afterward, when the payer's denial has already arrived and the only option left is an appeal. Philips Tasy, the hospital information system, already records everything needed: every item posted, by whom, in which department and at what time. What is missing is time to read each bill in full before it closes. The same approach applies to MV, the other major hospital system in Brazil.

How the patient bill is created and closed in Tasy

In Tasy, the patient bill opens at the point of care, whether an inpatient admission, the emergency department or an outpatient visit. From then on, each department posts what it consumes: the pharmacy dispenses drugs based on the prescription, nursing records supplies and procedures, the operating room posts the procedure, hospitality generates daily rates, and the lab and imaging post tests. Every posting carries item, quantity, department, user and time. Alongside it, the medical record holds the prescription, clinical notes and the health plan's authorization.

At discharge, the bill goes through closing. Billing reviews the items, applies the payer's rules and prices each one against the negotiated table: procedures by the contract table with TUSS codes (the unified terminology of Brazilian supplementary health), drugs by the Brasíndice price guide, materials by the Simpro price guide or the contracted price, plus daily rates and fees.

The closed bill is sent in batches per payer in the TISS standard, the mandatory data exchange format set by the ANS, Brazil's regulator of private health plans. The payer receives it, reviews it, and pays, denies items or returns it. In Brazil a payer's denial of a billed item is called a glosa. The payer's side of the process is covered in the article on medical claims audit at the payer.

Where the denial starts

The denial is issued by the payer, but it starts inside the hospital, before submission. The reasons repeat:

• Item without a prescription or clinical note. A drug dispensed without a prescription, a dressing billed with no nursing record.
• Price-table mismatch. A TUSS code different from the contract, material outside the negotiated Simpro price, a quantity above the standard.
• Missing authorization. A procedure, OPME (orthotics, prostheses and special materials) or ICU daily rate without the payer's authorization number, or with an expired authorization.
• Deadline. Bill sent after the contractual deadline, or appeal filed after the limit.
• Coding. A procedure incompatible with the diagnosis or with the size of the procedure actually performed.

All of these reasons already exist in the bill at closing. Whoever reads the whole bill before sending it can fix them. The article on hospital claim denials covers the types of denial and the appeal.

What traditional auditing does and why it arrives late

The hospital's internal audit, run by nurses and billing analysts, works by sample: the highest-value bills, payers with a history of denials, certain specialties. The rest close with the biller's check.

The denial arrives weeks after submission, in the payer's statement. The hospital opens a denial appeal, gathers the medical record and prescription, justifies and waits for the re-review. Part of the amount comes back, part does not, and cash sits idle.

Traditional auditing is not ineffective; it is late. It discovers on appeal what it could have fixed at closing. And because it works by sample, it lets through the small, repeated error that piles up across thousands of low-value bills.

What process mining sees in Tasy events

Process mining rebuilds the path of each bill from the events Tasy already records: opening of the encounter, each posting with department, user and time, discharge, closing, batch submission, denial received, appeal and payment.

With that timeline, the hospital knows where the bill waited between discharge and closing, which departments post after discharge, which payers deny most and why, and how long the appeal takes.

The picture separates two problems that show up together: a flow problem, when a department posts late, and a content problem, when the bill goes out with an error. The first is solved with process. The second is where the agent comes in. The same event base serves inpatient and discharge management.

What an AI agent does before the bill closes

The agent works between discharge and closing and reviews 100% of bills, not a sample. For each bill, it cross-checks the posted items against the prescription, clinical notes and authorizations, and against the rules of the payer's contract and price tables.

The result is not "approve" or "deny." It is a list of items with the likely denial reason and the suggested fix. An illustrative example: a medical admission with an antibiotic dispensed for five days and prescribed for three, a special dressing with no nursing record, and a private-room daily rate on a contract that provides for a shared ward. The agent points out the three items, the reason and what to do: adjust the quantity, find the record or correct the room type.

The agent learns from history. Every denial received, with its coded TISS reason, feeds what it looks for on the next bill for that payer.

The auditor decides, the agent prepares

Technical responsibility stays with the nurse auditor and the physician auditor. The agent does not change postings, does not close bills and does not write appeals on its own. It prepares: gathers evidence, points out the item, suggests the fix and explains the reason.

The auditor decides whether the deviation is justified by the clinical case, whether the fix applies or whether the bill goes out as is. Each decision is recorded with the item, the agent's suggestion and the auditor's choice.

Governance and LGPD

A patient bill is sensitive personal data under the LGPD, Brazil's data protection law, and three rules are non-negotiable. The data stays in the hospital's environment: the agent reads Tasy events where they are and does not copy medical records to a third-party cloud. Access is named, with the agent operating as a user with its own auditable profile. And the model is not trained on patient data: it learns from denial and bill patterns, not from identity. The legal basis is the protection of health and the performance of the contract with the payer.

Where to start

The first step is an export of Tasy events for a closed period: postings, closings, batches sent and denials received. Within a few weeks, process mining shows where bills wait and which payers deny most.

With that picture, the hospital picks one or two payers and one specialty for the agent to review before closing, with the auditor validating every flag. This is how UpFlux works: a digital team of AI agents operated by specialists, inside the systems the hospital already uses, with the auditor keeping the decision. The Tasy page describes how UpFlux runs the integration (the MV page covers the same for MV); the medical claims audit solution and the healthcare page show what we do for hospitals and payers.

Frequently asked questions

What is AI in Tasy for claims audit?

It is an AI agent that reads each patient bill in Tasy before it closes, cross-checks the posted items against the prescription, clinical notes, authorization and the payer's price tables, and points out the items with a likely denial reason and the suggested fix. The auditor decides. UpFlux applies this approach on Tasy's own events, without taking patient data out of the hospital.

Does the agent replace the claims auditor?

No. The nurse auditor and the physician auditor remain responsible for the decision, as the rules of Brazil's Federal Nursing Council (COFEN) and Federal Council of Medicine (CFM) require. The agent prepares: it reviews 100% of bills, finds the item, explains the reason and suggests the fix. The auditor decides on problems already found instead of searching for them in a sample.

How does the agent learn from each payer's denials?

Every denial statement carries the item, the amount and the reason coded in the TISS standard. The agent links that history to the payer, the specialty and the item type, and starts checking first what that payer tends to deny. The review before closing reflects each payer's real behavior, not a generic rule.

Does the same approach work in MV?

Yes. MV records the patient bill with the same logic of postings by department, closing and TISS billing, and it records the events needed for process mining and for the review before closing. UpFlux works on Tasy and MV events with the same method and the same governance of patient data.