Charges and Billing with DFT

From clinical event to claim

Every billable thing that happens to a patient — a lab run, an imaging study, a dose of medication, a visit with a clinician — eventually has to turn into money. The system that does the clinical work (the lab analyzer, the radiology system, the pharmacy) is rarely the system that produces the bill. Something has to carry the fact that “this chargeable thing happened to this patient during this encounter” from the clinical world to the billing or patient-accounting world. In HL7 v2 that something is the DFT, the Detailed Financial Transaction message ¹.

This connects directly to the order-and-result workflow seen earlier in the course. When an order is completed or a procedure is performed, an ancillary system “drops a charge”: it emits a DFT message describing what was done and what it costs. The billing system consumes that message, accumulates the charges for an encounter, and ultimately assembles a claim. The DFT is the bridge between care and revenue ².

The DFT message family

The most common member of the family is DFT^P03, the post-detail-financial-transaction message. Like every v2 message, its type and trigger event live in MSH-9, and the patient and visit are identified by the PID and PV1 segments already familiar from ADT. What makes DFT distinct is its payload segment, FT1, which carries the financial detail. A single DFT message may contain several FT1 segments — for example, several line items produced by one completed procedure.

DFT is event-driven in the same spirit as ADT: a real-world occurrence (the charge being ready to post) triggers a message. It is worth remembering that other workflows feed the same billing pipeline — for instance, an ADT A03 discharge can itself trigger downstream billing activity — but DFT is the message dedicated to moving the charge detail itself.

Anatomy of a DFT^P03

A minimal DFT^P03 reuses segments already covered and adds the financial detail:

MSH|^~\&|RADIOLOGY|HOSP|BILLING|HOSP|20260601093000||DFT^P03|MSG00012|P|2.5.1
EVN|P03|20260601093000
PID|1||100245^^^HOSP^MR||DOE^JANE||19800214|F
PV1|1|O|RAD^^^HOSP||||4471^SMITH^ALAN
FT1|1|||20260601|20260601|CG|71046^Chest X-ray 2 views^CPT|||1|85.00|||RADIOLOGY
PR1|1||71046^Chest X-ray 2 views^CPT|Chest radiograph|20260601

Here MSH and EVN announce the message and its trigger; PID and PV1 tie the charge to a specific patient and a specific encounter (the same identity and visit context used throughout the course); FT1 carries the chargeable line item; and the optional PR1 segment supplies procedure context for that charge.

Walking the key FT1 fields

FT1 is where the money lives, so its fields repay close reading ¹:

• Transaction date — when the chargeable event occurred. Billing and compliance both depend on accurate dates, and they may differ from the date the message was sent.
• Transaction type — the nature of the entry: CG for a charge, CD for a credit, and other codes for adjustments or payments. This single code decides whether the line adds to or subtracts from the account.
• Transaction code — the chargeable item itself, typically expressed with a coded identifier such as a CPT or HCPCS-style procedure code. This is what the billing system prices and what ultimately appears on a claim.
• Quantity — how many units of the item (two views, three vials, and so on).
• Amount — the monetary value of the line, used together with quantity.
• Department — the cost center or ancillary department that performed the work, which matters for internal accounting and reporting.
• Performing and ordering provider — who did the work and who requested it, both of which can affect reimbursement and attribution.

The optional PR1 (Procedures) segment complements FT1 by describing the clinical procedure behind the charge, giving the billing system richer context than the charge code alone.

Why the plumbing matters

DFT looks like dry accounting, but its reliability has real stakes. If a charge message is lost, the work was done but never billed — direct lost revenue. If a charge is sent twice, the patient or payer is overcharged, which is a compliance and trust problem. Because DFT sits at the seam between clinical and financial systems, interface teams watch it closely: reconciling that every completed order produced exactly one set of charges is a routine, and consequential, part of running a v2 environment ².