HL7 DFT_P03 (Post Detail Financial Transaction) | Integration Soup HL7 Reference Guide

HL7 DFT_P03 Post Detail Financial Transaction

The message that moves charge lines into patient accounting.

HL7 message structure DFT_P03 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
EVN	Event Type	Yes	No
PID	Patient Identification	Yes	No
PD1	Patient Additional Demographic	No	No
ROL	Role	No	Yes
PV1	Patient Visit	No	No
PV2	Patient Visit - Additional Information	No	No
ROL	Role	No	Yes
DB1	Disability	No	Yes
DFT_P03.COMMON_ORDER	Common Order group	No	Yes
ORC	Common Order	No	No
DFT_P03.TIMING_QUANTITY	Timing Quantity group	No	Yes
TQ1	Timing/Quantity	Yes	No
TQ2	Timing/Quantity Relationship	No	Yes
DFT_P03.ORDER	Order group	No	No
OBR	Observation Request	Yes	No
NTE	Notes and Comments	No	Yes
DFT_P03.OBSERVATION	Observation group	No	Yes
OBX	Observation/Result	Yes	No
NTE	Notes and Comments	No	Yes
DFT_P03.FINANCIAL	Financial group	Yes	Yes
FT1	Financial Transaction	Yes	No
NTE	Notes and Comments	No	No
DFT_P03.FINANCIAL_PROCEDURE	Financial Procedure group	No	Yes
PR1	Procedures	Yes	No
ROL	Role	No	Yes
DFT_P03.FINANCIAL_COMMON_ORDER	Financial Common Order group	No	Yes
ORC	Common Order	No	No
DFT_P03.FINANCIAL_TIMING_QUANTITY	Financial Timing Quantity group	No	Yes
TQ1	Timing/Quantity	Yes	No
TQ2	Timing/Quantity Relationship	No	Yes
DFT_P03.FINANCIAL_ORDER	Financial Order group	No	No
OBR	Observation Request	Yes	No
NTE	Notes and Comments	No	Yes
DFT_P03.FINANCIAL_OBSERVATION	Financial Observation group	No	Yes
OBX	Observation/Result	Yes	No
NTE	Notes and Comments	No	Yes
DG1	Diagnosis	No	Yes
DRG	Diagnosis Related Group	No	No
GT1	Guarantor	No	Yes
DFT_P03.INSURANCE	Insurance group	No	Yes
IN1	Insurance	Yes	No
IN2	Insurance Additional Information	No	No
IN3	Insurance Additional Information, Certification	No	Yes
ROL	Role	No	Yes
ACC	Accident	No	No

DFT_P03 carries detailed financial transactions such as charges, payments, adjustments, and ancillary billing details. It is usually sent from a departmental system, order filler, charge processor, or integration engine to a billing or patient accounting system.

DFT is where clinical workflow meets money. That means identifiers matter. The receiver needs to know the patient, visit, account, service, transaction, provider, diagnosis, procedure, and sometimes the related order. One missing account or mismatched visit can turn a clean clinical event into a billing exception.

A small DFT charge example

MSH|^~\&|LAB|CITYHOSP|BILLING|CITYHOSP|20260715160000||DFT^P03^DFT_P03|DFT00042|P|2.5.1 EVN|P03|20260715155800 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|O|CLINIC^12^^CITYHOSP||||12345^Careful^Clara|||||||||||VN000345^^^CITYHOSP^VN FT1|1|TXN0001|CHG|20260715143000|20260715143000|CG|85025^Complete blood count^CPT|Complete blood count|1|125.00|NZD DG1|1||R07.9^Chest pain, unspecified^I10|||A IN1|1|PLAN-A|INS001|City Health Plan

What systems do with it

The sender posts financial activity after a service is performed, verified, or otherwise billable. The receiver posts it to patient accounting, claims, reporting, or reconciliation. Some DFT feeds are near real time; others are batch-like and arrive after departmental review.

FT1 is the center of the message. It carries transaction identifiers, transaction type, dates, charge codes, quantities, amounts, departments, providers, and related financial details. The patient and visit context around it is what lets accounting post the transaction to the right place.

How to read the structure

The v2.5.1 structure can carry patient, visit, common order, observation, financial, diagnosis, guarantor, insurance, and accident groups. The required repeating financial group contains FT1 and optional notes, procedures, and order detail. That lets a DFT represent simple charge lines or charge lines tied to orders and results.

If common order information is present, ORC and OBR should describe the order context without accidentally creating a new order at the billing receiver. The financial transaction is still the main event.

Implementation traps

Make reversals and corrections explicit. Some receivers support DFT_P11 or local void/correction rules; others expect negative charges or adjustment transaction types. Agree this early. Billing corrections are not a place for creative interpretation.

Also watch duplicate control. A sender retry after no ACK should not post the same charge twice. Use transaction IDs, message control IDs, and receiver-side duplicate checks deliberately.

Reference notes

The HL7 v2+ refactored DFT_P03 page describes DFT as a financial transaction message to billing systems for ancillary charges, deposits, and related ordered services. Vendor summaries such as iNTERFACEWARE's DFT overview align with that practical billing focus.