HL7 DFT_P11 (Post Detail Financial Transactions - Expanded/New)

HL7 DFT_P11 Post Detail Financial Transactions - Expanded

A billing transaction message with more room for order, diagnosis, insurance, and procedure context.

HL7 message structure DFT_P11 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_P11.COMMON_ORDER	Common Order group	No	Yes
ORC	Common Order	No	No
DFT_P11.TIMING_QUANTITY	Timing Quantity group	No	Yes
TQ1	Timing/Quantity	Yes	No
TQ2	Timing/Quantity Relationship	No	Yes
DFT_P11.ORDER	Order group	No	No
OBR	Observation Request	Yes	No
NTE	Notes and Comments	No	Yes
DFT_P11.OBSERVATION	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_P11.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_P11.FINANCIAL	Financial group	Yes	Yes
FT1	Financial Transaction	Yes	No
DFT_P11.FINANCIAL_PROCEDURE	Financial Procedure group	No	Yes
PR1	Procedures	Yes	No
ROL	Role	No	Yes
DFT_P11.FINANCIAL_COMMON_ORDER	Financial Common Order group	No	Yes
ORC	Common Order	No	No
DFT_P11.FINANCIAL_TIMING_QUANTITY	Financial Timing Quantity group	No	Yes
TQ1	Timing/Quantity	Yes	No
TQ2	Timing/Quantity Relationship	No	Yes
DFT_P11.FINANCIAL_ORDER	Financial Order group	No	No
OBR	Observation Request	Yes	No
NTE	Notes and Comments	No	Yes
DFT_P11.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_P11.FINANCIAL_INSURANCE	Financial 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

DFT_P11 is the expanded post detail financial transaction message. It serves the same broad family of workflows as DFT_P03: moving charges, payments, adjustments, and related financial events from clinical or ancillary systems into patient accounting or revenue-cycle systems.

The practical difference is shape and intent. P11 gives the transaction more structured context around orders, diagnoses, procedures, guarantors, insurance, and related observations. Some sites use it for richer charge posting. Some use local P03 conventions instead. The first integration question is not "does the standard allow it?" but "does this billing receiver actually implement P11?"

A small DFT_P11 example

MSH|^~\&|RAD|CITYHOSP|BILLING|CITYHOSP|20260715123000||DFT^P11^DFT_P11|DFT110001|P|2.5.1 EVN|P11|20260715123000 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|O|RAD^XRAY1^1^CITYHOSP||||12345^Ordering^Olivia DG1|1||R079^Chest pain, unspecified^I10|||A IN1|1|PLAN123^City Health Plan^L|CHP|City Health Plan|100 Benefit Road^^Auckland^^1010^NZ FT1|1|TX99801|BATCH20260715|20260715103000|20260715120000|CG|71046^Chest xray two views^CPT|Chest xray two views|1|150.00^USD|150.00^USD|RAD^Radiology^L||||O||||12345^Reader^Riley

What systems do with it

The sender is often an ancillary clinical system, departmental system, ADT/accounting component, or integration engine. The receiver is usually patient accounting, billing, claims, or a revenue-cycle platform. The message may post a new charge, identify an adjustment, or carry a locally defined financial action.

FT1 is the center of gravity. It carries transaction dates, type, code, quantity, amounts, department, diagnosis linkage, and provider detail. PID identifies the patient, PV1 identifies the encounter when present, DG1 and DRG support diagnosis context, GT1 supports guarantor detail, and IN1 with IN2/IN3 supports payer context.

How to read the structure

DFT_P11 starts with the message, event, patient, and visit layer. It can include a common-order group before the financial transactions, which is useful when the charge is tied to an order and result context through ORC, OBR, TQ1, and OBX.

The required financial group repeats. Each repetition starts with FT1 and can add procedure detail in PR1, its own order context, diagnosis, guarantor, and insurance detail. That lets one message carry several charge lines, but it also means the receiver has to know whether transaction-level insurance should override or complement patient-level insurance.

Implementation traps

The first trap is assuming P11 support. Many billing interfaces are strongly profiled and expect one local pattern. If the receiver only supports P03 or a custom P03 reversal convention, a beautifully structured P11 will still fail.

The second trap is losing the accounting identity. FT1 transaction ID, batch ID, transaction type, charge code, quantity, amount, department, and service date usually matter more to billing than the clinical display text. Keep those fields stable enough that voids, corrections, and reconciliation can be tied back to the original transaction.

The third trap is repeating insurance and diagnosis context in two places without a rule. P11 can carry these at the patient level and inside the financial group. Decide which one wins when they disagree.

Reference notes

The HL7 v2+ DFT_P11 page describes the expanded DFT as a financial transaction between systems, such as ancillary charges or ADT-to-billing deposits. The HL7 v2.5.1 financial chapter describes FT1 as the detail data used to post charges, payments, adjustments, and similar patient-accounting records. iNTERFACEWARE's DFT overview gives the same practical billing and accounts-receivable framing.