HL7 DFT Messages Explained: Detailed Financial Transactions

DFT stands for Detailed Financial Transaction. When a health service does something chargeable — a procedure, a bed day, a consumable, an imaging study — a DFT message carries that fact from the clinical system that recorded it to the financial system that will bill for it.

It is the least glamorous message type in HL7 and, in commercial terms, frequently the most consequential. Clinicians never see it. Finance depends on it entirely. And unlike most integration failures, DFT failures have an obvious unit of measurement: money that was earned and not claimed.

The structure

The common message is DFT^P03, post-detail financial transaction:

• PID — the patient.
• PV1 — the visit or encounter the charges belong to.
• FT1 — the financial transaction detail. One per chargeable item.
• PR1 — procedure information, where the charge relates to a coded procedure.
• DG1 — diagnosis, which frequently determines whether and how something can be claimed.

FT1 is where the substance is: transaction date, transaction type (charge, credit, adjustment), the charge code, quantity, amount, the department, and the performing and ordering providers.

Why billing interfaces are unforgiving

Duplicates cost real money, in both directions. A charge sent twice is a patient or funder billed twice — a compliance problem, not just an accounting one. A charge dropped is revenue permanently lost, and unlike a missing result, nobody downstream is waiting for it and nobody notices. Idempotency is not a nice-to-have here. Every transaction needs a stable identifier the receiver can use to recognise a repeat.

Reversals and adjustments are ordinary traffic. Procedures get cancelled after the charge is raised. Codes get corrected. Quantities change. A DFT interface that only handles positive charges is half an interface, and the missing half is the one finance will ask about.

Charge codes must match the master file. DFT references codes from the charge description master, which is itself distributed by MFN messages. When the two drift apart, charges arrive referencing codes the financial system does not recognise. Depending on configuration they either reject — visibly, which is the good outcome — or land in a suspense account nobody reviews.

Timing matters in a way it does not elsewhere. Financial periods close. A charge that arrives after the period it belongs to has been closed is a genuine accounting problem, not just a late message. Interfaces that catch up after an outage by replaying everything can dump weeks of backdated transactions into a closed period.

The reconciliation obligation

Every DFT interface needs a reconciliation, and it is the clearest example of why message-level monitoring is not enough. Counting messages sent and received tells you nothing about whether the totals agree.

The reconciliation that matters compares activity to charges: how many procedures were recorded in the clinical system in a period, how many charges reached the financial system, and what the value difference is. That comparison finds the failure mode that message counting never will — charges that were never generated in the first place, because a workflow changed and nobody updated the charge trigger.

I have written about this pattern more generally in ten out of twelve is a failure, not a result. Financial interfaces are where the argument is easiest to win, because the missing two have a dollar value attached.

Australian context

In Australia, what happens after the DFT depends heavily on the setting. Public hospital activity feeds activity-based funding, with its own classification and reporting obligations. Private hospital and specialist billing runs through Medicare and private health insurer claiming, with the MBS item numbers, health fund rules and eligibility checks that come with it. The DFT interface itself is only the first hop, and its output has to be good enough to survive everything downstream of it.

That has a practical consequence for design: the charge data needs to carry enough clinical context — diagnosis, procedure coding, provider — for the claiming process to work. A DFT interface that transmits a charge code and an amount, and nothing else, pushes the problem to whoever has to assemble the claim.

Practical advice

Give every transaction a stable, unique identifier and make the receiver idempotent on it. Handle reversals and adjustments from day one. Reconcile on value, not on message count. Keep the charge master synchronised and monitored. And make sure someone in finance, not just someone in IT, receives the exception report — the person who can tell whether a variance matters is not usually the person watching the interface.

FHIR models this domain with ChargeItem, Claim, Account and Invoice. The resources are considerably more expressive than FT1. The commercial obligation is identical: bill once, bill correctly, and be able to prove what you sent.

If your billing interface is leaking revenue or generating duplicates, that is a solvable problem.