HL7 DFT Messages: Detailed Financial Transactions

HL7 DFT messages carry detailed financial transactions — the charges, payments, and adjustments that one system posts to another, most often from a clinical or ancillary system to the billing or patient-accounting system. DFT is the message integrators reach for when an event that happened in care needs to become a line on an account: a procedure performed, a supply consumed, a deposit taken. This page explains what a DFT message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how a DFT transaction relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What a DFT message represents

A DFT message — DFT stands for Detailed Financial Transactions — communicates one or more financial transactions for a patient. The core of the message is the FT1 segment, which carries the detail needed to post a single transaction: its type, its code, the quantity, and the amount. A transaction can be a charge, a payment, an adjustment, or a credit, distinguished by the transaction type in FT1.

The sender is typically a clinical or ancillary system — the system that knows a billable event occurred — and the receiver is the billing or patient-accounting system that turns the transaction into an account entry. DFT sits downstream of the events that generate charges: a performed procedure, a dispensed medication, a consumed supply, or an admission deposit. Because the message reports a transaction that has already happened, the FT1 segment is the authoritative record of what should be posted, not a request to be negotiated.

Every DFT message shares the same skeleton — an MSH header, an EVN event segment, a PID patient segment, and at least one FT1 financial transaction — and the financial detail lives in the repeating FT1.

When a DFT message is sent

A DFT message is sent when a billable event occurs and needs to reach the account. Common triggers include a charge for an ancillary service after the service is rendered, a patient deposit captured at registration, or an adjustment posted to correct a prior charge. A single message can carry several transactions, because the financial group repeats — a visit that generated multiple charges can post them together.

Trigger event

The DFT message type carries a single commonly used trigger event:

• DFT^P03 – Post detail financial transactions.

Because the relevant DFT structure has one trigger event, the receiver's handling turns on the contents of FT1 — the transaction type, code, quantity, and amount — rather than on the trigger code in MSH-9. A charge, a payment, and an adjustment all arrive as DFT^P03; the transaction type in FT1-6 distinguishes them.

Integration topology

The diagram shows a clinical or ancillary system emitting a financial transaction through the integration engine to the systems that post and reconcile it.

{{diagram: clinical/ancillary system → DFT message → integration engine → billing / patient accounting / charge capture}}

Typical senders: clinical or ancillary systems (laboratory, radiology, pharmacy), registration, and charge-capture applications.

Typical receivers: billing system, patient-accounting system, and charge-capture or revenue-cycle platforms.

Direction: unidirectional notification from the system that recognises a charge to the system that posts it to the account.

Segments in a DFT message

The DFT_P03 message is organised around a required, repeating FINANCIAL group that opens with FT1. Optional patient-visit, order, diagnosis, guarantor, and insurance segments surround it to supply the context a charge needs. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The FINANCIAL group repeats once per transaction, so a single DFT message can report several charges, payments, and adjustments at once. The surrounding visit, diagnosis, guarantor, and insurance segments supply the account context the receiver needs to post them. The canonical segment pages carry the full field-by-field detail.

The FT1 financial transaction segment

FT1 — the Financial Transaction segment — carries the detail needed to post a single charge, payment, or adjustment. The fields an integration team reads most often:

The transaction type in FT1-6 and the transaction code in FT1-7 together define what is being posted and against which service; the amount in FT1-11 and the quantity in FT1-10 define how much. These are the fields a billing receiver acts on first. The full field list, including insurance, ordering, and procedure-modifier fields, is on the canonical FT1 page.

Sample DFT message

Note. Constructed for illustration. Patient identifiers, account numbers, codes, dates, and names are fictional.

MSH|^~&|LAB|MERCYGEN|BILLING|MERCYGEN|202006151015||DFT^P03^DFT_P03|MSG00021|P|2.5.1
EVN|P03|202006151015
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
PV1|1|O|LAB^^^MERCYGEN||||1234^SMITH^JANE^A^^^MD|||MED
FT1|1||BATCH07|202006151000|202006151015|CG|85025^CBC with differential^LN|||1|45.00|45.00|LAB

What this sample shows

The DFT^P03 in MSH-9 marks a detailed financial transaction, and the matching P03 in EVN repeats the trigger with its timestamp. PID carries the medical record number MR12345, and PV1 places the patient as an outpatient (O) in the lab with an attending provider, giving the charge its visit context. The single FT1 posts one charge: a transaction type of CG in FT1-6, the service code in FT1-7, a quantity of 1 (FT1-10), a total amount of 45.00 (FT1-11) and a unit amount of 45.00 (FT1-12), originating from the LAB department (FT1-13). The transaction date is in FT1-4 and the posting date in FT1-5.

Working with DFT messages

Read the transaction type before posting

The transaction type in FT1-6 tells the receiver whether the transaction is a charge, a payment, an adjustment, or a credit — which determines how it affects the account balance. Posting every FT1 as a charge, regardless of type, corrupts the account; switch on FT1-6 first.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the transaction id in FT1-2 as the natural business key for an individual transaction. Financial feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed message from posting the same charge twice.

Multiple transactions per message

The FINANCIAL group repeats, so a single DFT message can carry several transactions. Process each FT1 independently and post all of them, rather than reading only the first — a visit that generated several charges posts them in one message.

Amounts and quantities

The amount lives in FT1-11 (extended, the total) and FT1-12 (unit), with the quantity in FT1-10. Read the field the partner populates rather than assuming, and preserve the currency and sign exactly — an adjustment or credit may carry a negative amount.

Vendor variance. DFT predates many of the optional groups in the current structure, and senders differ widely in how much context they include — some send only MSH, EVN, PID, and FT1, while others populate the visit, order, diagnosis, and insurance segments. Confirm a partner's field and segment usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A detailed financial transaction corresponds, conceptually, to FHIR financial resources — a charge maps naturally onto ChargeItem, posted against an Account, and aggregated into an Invoice. The patient is a Patient resource, and for a messaging exchange a MessageHeader heads the Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for DFT_P03 — the published message maps cover only an ADT subset and OML_O21, ORM_O01, VXU_V04, ORU_R01, MDM_T02, and SIU_S12 — and no ConceptMap for the FT1 financial transaction segment; among the financial-management segments, the IG publishes ConceptMaps for DG1, IN1, IN3, and PR1, but not for FT1. A FHIR representation produced from a DFT message is therefore mapped manually, taking the transaction type, code, quantity, and amount from FT1 and referencing the patient and encounter for context.

Common pitfalls

Pitfall. Treating every transaction as a charge. FT1-6, the transaction type, distinguishes charges, payments, adjustments, and credits; ignoring it posts payments and credits as charges and breaks the account balance.

Pitfall. Reading only the first FT1. The FINANCIAL group repeats, so a message can carry several transactions; processing only the first drops the rest.

Pitfall. Assuming a fixed date-time precision. Some senders stamp FT1-4 and FT1-5 as YYYYMMDD and others as a full timestamp with an offset; do not assume a timezone — normalize on ingest.

How Vorro handles DFT messages

Vorro ingests the DFT feed over MLLP or another transport, deduplicates on MSH-10, and routes each transaction to every subscribed destination in the format that system expects — the billing and patient-accounting systems. Vorro reads the transaction type, code, quantity, and amount from each FT1, processes every transaction in the repeating financial group, and, where a FHIR destination is configured, maps the transaction to financial resources such as ChargeItem and Account — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• BAR — add or change billing-account messages that establish the account a DFT transaction posts against.
• ADT — the patient administration feed that establishes the patient and visit context a charge attaches to.
• ORM — orders that generate the services later posted as financial transactions.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for DFT_P03
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for FT1
• HL7 Messaging Standard Version 2.5.1 product brief
• HAPI HL7v2 v2.5.1 DFT_P03 message structure
• HAPI HL7v2 v2.5.1 FINANCIAL group structure
• HAPI HL7v2 v2.5.1 COMMON_ORDER group structure
• HAPI HL7v2 v2.5.1 FINANCIAL_PROCEDURE group structure
• HAPI HL7v2 v2.5.1 FT1 segment definition </content>

</invoke>