HL7 DFT Billing Messages: P03/P11, FT1, PR1, DG1 Explained

The HL7 DFT (Detailed Financial Transaction) message is the single most important HL7 v2 message type your revenue cycle depends on, and the one most often mishandled by integration teams. Every charge, payment, adjustment, and void that needs to move from a clinical or ADT system into a billing or patient-accounting system rides a DFT. When DFT channels are clean, claims flow; when DFT channels are broken, charges silently drop and weeks of revenue evaporate before anyone notices.

This guide is the complete senior-engineer reference we use when we onboard a new DFT channel, audit an existing one, or rebuild a broken charge pipeline. It covers trigger events, segment-by-segment content, CPT and ICD-10 coding placement, insurance and guarantor handling, hospital versus professional billing patterns, and the downstream mapping into 837 claims — with real HL7 samples drawn from production patterns.

For broader HL7 v2 structural context, start with our HL7 v2 message structure guide and the full HL7 integration pillar. For how DFT fits alongside ORU and ORM in a complete clinical-to-billing flow, see HL7 ORM/ORU lab workflow.

1. What Is a DFT Message?

A DFT message moves a financial transaction between systems. A financial transaction in HL7 terms is one of:

Charge (CG) — a billable service or supply that should become a claim line.
Payment (PY) — money received against a patient account.
Adjustment (AJ) — a write-off, discount, or correction to a balance.
Credit (CR) — a negative charge that reverses a previously posted item.

DFT is used when the sending system (an EHR, an OR system, a clinical charge-capture app, a nursing documentation module) needs to inform the receiving system (a patient-accounting platform, a practice-management system, a charge-consolidation engine, or a claims clearinghouse bridge) that a new financial event has occurred for a specific patient.

DFT is a pure financial message. It is not a clinical document — it references clinical context (diagnoses, procedures, visits) only to the degree required to price, code, and bill the charge. For clinical results, ORU is used; for orders, ORM; for patient demographic and visit updates, ADT.

Unlike ADT which often fires at every visit event, DFTs typically fire only when a chargeable event has been confirmed — usually at the moment a service is documented, a procedure is signed off, a pharmacy dispense is committed, or an OR case closes. This means DFT volumes are lower than ADT but every DFT carries direct revenue impact, making message reliability disproportionately important.

2. DFT Trigger Events (P03, P11, and Others)

The trigger event appears in MSH-9 as the second component (e.g., DFT^P03). The most common triggers you will see in US production:

P03 — Post Detail Financial Transaction. The default. A new charge, payment, or adjustment is being posted. Over 90% of DFT traffic in most environments is P03.
P11 — Post Detail Financial Transactions — New Description. Added in HL7 v2.5. Used to void, correct, or replace a previously posted P03. Not all receivers implement P11; many use "P03 with negative amount" as their reversal pattern instead.
P12 — Update Detail Financial Transaction. Rarely used outside a few niche systems; modifies a previously posted transaction without voiding it.

If you are building a new DFT channel and the receiver documentation says "we accept DFT" without naming a trigger, it almost certainly means P03 with negative-amount reversals. Confirm this explicitly before going live; a misread here causes double-billing or dropped reversals.

Minimal P03 sample

MSH|^~\&|EPIC|HOSPITAL|SIEMENS|BILLING|20260421103012||DFT^P03|MSG00001|P|2.5
EVN|P03|20260421103012
PID|1||MRN12345^^^HOSPITAL^MR||SMITH^JOHN^A||19780412|M|||123 MAIN ST^^BOSTON^MA^02115||6175551212|||S||ACCT987654
PV1|1|O|CLINIC-A^^^HOSPITAL||||1234567890^JONES^SARAH^M^^^MD|||SURG||||||||12345|||||||||||||||||||||||||20260421103012
FT1|1|TX20260421001|BATCH-042126|20260421|20260421|CG|99213^OFFICE VISIT LEVEL 3^CPT|||1|125.00|||CLINIC-A||M25.561^RIGHT KNEE PAIN^I10||1234567890^JONES^SARAH^M^^^MD
DG1|1|I10|M25.561^RIGHT KNEE PAIN^I10|||F

P11 void sample

MSH|^~\&|EPIC|HOSPITAL|SIEMENS|BILLING|20260421150022||DFT^P11|MSG00047|P|2.5
EVN|P11|20260421150022|||OPERATOR123
PID|1||MRN12345^^^HOSPITAL^MR||SMITH^JOHN^A||19780412|M|||123 MAIN ST^^BOSTON^MA^02115||6175551212|||S||ACCT987654
PV1|1|O|CLINIC-A^^^HOSPITAL||||1234567890^JONES^SARAH^M^^^MD|||SURG|||||||||||||||||||||||||||||||20260421103012
FT1|1|TX20260421001-VOID|BATCH-042126|20260421|20260421|CR|99213^OFFICE VISIT LEVEL 3^CPT|||1|-125.00|||CLINIC-A||M25.561^RIGHT KNEE PAIN^I10||1234567890^JONES^SARAH^M^^^MD|||||||TX20260421001

Note the CR transaction type, the negative amount in FT1.11, and the reference to the original transaction ID in the trailing FT1 fields. Always include the original transaction reference when voiding — auditors and downstream reconciliation jobs will ask for it.

3. Full DFT Message Structure

The abstract DFT^P03 message structure in HL7 v2.5:

DFT^P03 message
  MSH                  Message Header                [1..1] required
  {SFT}                Software Segment              [0..*] optional
  EVN                  Event Type                    [1..1] required
  PID                  Patient Identification        [1..1] required
  [PD1]                Patient Additional Demographic [0..1]
  [{ROL}]              Role                          [0..*]
  [PV1                 Patient Visit                 [0..1]
    [PV2]              Patient Visit Additional       [0..1]
  ]
  [{DB1}]              Disability                    [0..*]
  [{OBX}]              Observation                   [0..*]
  {
    FT1                Financial Transaction         [1..*] REPEATING
    [{NTE}]            Notes and Comments            [0..*]
    [{DG1}]            Diagnosis                     [0..*]
    [DRG]              Diagnosis Related Group       [0..1]
    [{GT1}]            Guarantor                     [0..*]
    [{
      IN1              Insurance                     [1..1]
      [IN2]            Insurance Additional          [0..1]
      [{IN3}]          Insurance Additional 2        [0..*]
    }]
    [{ACC}]            Accident                      [0..*]
    [{CTD}]            Contact Data                  [0..*]
  }
  [DG1]                Diagnosis (header-level)      [0..1]

A single DFT message can carry multiple FT1 segments, each representing one financial transaction. In practice, hospital charge-capture systems send one FT1 per message for simplicity, while OR and pharmacy systems often bundle 5 to 50 FT1 segments into a single DFT to preserve transactional atomicity — if any one charge fails validation, the whole batch should be rejected.

Multi-FT1 sample (OR case)

MSH|^~\&|ORACLE-OR|HOSPITAL|EPIC|BILLING|20260421160000||DFT^P03|MSG00108|P|2.5
EVN|P03|20260421160000
PID|1||MRN77234^^^HOSPITAL^MR||GARCIA^MARIA^L||19620803|F|||55 OAK AVE^^BOSTON^MA^02118||6175553434|||M||ACCT112233
PV1|1|I|5NORTH^525^01^HOSPITAL||||9876543210^CHEN^DAVID^H^^^MD|||SURG||||||||67890|||||||||||||||||||||||||20260421080000|20260421160000
FT1|1|OR20260421-A|BATCH-OR-042126|20260421|20260421|CG|27447^TOTAL KNEE ARTHROPLASTY^CPT||RT|1|4250.00|||5NORTH||M17.11^PRIMARY OA RIGHT KNEE^I10||9876543210^CHEN^DAVID^H^^^MD
FT1|2|OR20260421-B|BATCH-OR-042126|20260421|20260421|CG|99140^ANESTHESIA EMERGENCY^CPT|||1|180.00|||5NORTH||M17.11^PRIMARY OA RIGHT KNEE^I10||5544332211^PATEL^ANIL^R^^^MD
FT1|3|OR20260421-C|BATCH-OR-042126|20260421|20260421|CG|L8699^PROSTHETIC IMPLANT^HCPCS|||1|3750.00|||5NORTH||M17.11^PRIMARY OA RIGHT KNEE^I10||9876543210^CHEN^DAVID^H^^^MD
FT1|4|OR20260421-D|BATCH-OR-042126|20260421|20260421|CG|99356^PROLONGED SERVICE^CPT|||1|235.00|||5NORTH||M17.11^PRIMARY OA RIGHT KNEE^I10||9876543210^CHEN^DAVID^H^^^MD
DG1|1|I10|M17.11^PRIMARY OA RIGHT KNEE^I10|||F
DG1|2|I10|E11.9^TYPE 2 DIABETES^I10|||F
DG1|3|I10|I10.^ESSENTIAL HYPERTENSION^I10|||F
PR1|1|I10|0SRC0J9^RESURFACE RIGHT KNEE JOINT^ICD10PCS|TOTAL KNEE ARTHROPLASTY|20260421100000|01
GT1|1||SAME^AS^PATIENT
IN1|1|BCBSMA001|BCBSMA|BLUE CROSS BLUE SHIELD MA||||GRP12345||||||||GARCIA^MARIA^L|SELF|19620803|55 OAK AVE^^BOSTON^MA^02118||||||||||||||||XYZ987654321
IN2|1||123456789

4. The FT1 Segment — Financial Transaction Detail

FT1 is the heart of DFT. Every field matters for downstream billing. The fields you will touch in almost every production implementation:

FT1 field-by-field reference

FT1.1 — Set ID. Sequential number starting at 1 within the message. Used to order the transactions.
FT1.2 — Transaction ID. The sending system's unique identifier for this transaction. Critical for reconciliation and void tracking.
FT1.3 — Transaction Batch ID. Batch number if the sender groups transactions; otherwise empty.
FT1.4 — Transaction Date. When the financial event occurred (not when the message was sent).
FT1.5 — Transaction Posting Date. When it should be posted to the general ledger / patient account.
FT1.6 — Transaction Type. CG (charge), PY (payment), AJ (adjustment), CR (credit), etc. Required.
FT1.7 — Transaction Code. The CPT, HCPCS, revenue code, or local charge code. This is the primary billable identifier.
FT1.8 — Transaction Description. Human-readable; often ignored by downstream systems but useful for audit.
FT1.9 — Transaction Description Alternative. Secondary description.
FT1.10 — Transaction Quantity. Usually 1; pharmacy and supply transactions may have higher quantities.
FT1.11 — Transaction Amount Extended. Total dollar amount for this line (unit price × quantity). This is what hits the patient account.
FT1.12 — Transaction Amount Unit. Per-unit price (optional).
FT1.13 — Department Code. Cost center / department.
FT1.14 — Health Plan ID. Rarely populated; most implementations carry insurance in IN1.
FT1.16 — Assigned Patient Location. Where the service was rendered.
FT1.19 — Diagnosis Code FT1. Primary diagnosis for this specific charge (used for charge-level linkage).
FT1.20 — Performed By Code. The rendering provider's NPI and name.
FT1.21 — Ordered By Code. The ordering provider (different from rendering for many tests/imaging).
FT1.22 — Unit Cost. Your internal cost basis — rarely sent externally.
FT1.25 — Procedure Code. Alternative placement for CPT when FT1.7 is used for a local charge code.
FT1.26 — Procedure Code Modifier. CPT modifiers (RT, LT, 25, 59, etc.) — critical for professional billing.

FT1 with modifiers and performing provider

FT1|1|TX20260421-IMG|BATCH-IMG|20260421|20260421|CG|73564^KNEE XRAY COMPLETE^CPT||RT|1|95.00|95.00||RAD-01||M25.561^RIGHT KNEE PAIN^I10||2233445566^KUMAR^PRIYA^N^^^MD|1234567890^JONES^SARAH^M^^^MD|||||73564^KNEE XRAY COMPLETE^CPT|26^PROFESSIONAL COMPONENT

The modifier 26 (professional component) tells downstream billing to bill only the reading-physician portion of the knee X-ray. The RT in FT1.9 indicates laterality. Both are essential for the 837P to be clean on the first pass.

5. DG1 and PR1 — Diagnosis and Procedure Coding

DG1 carries diagnoses; PR1 carries procedures. On a professional (office-based) DFT, DG1 is typically populated and PR1 is rare. On an institutional (hospital inpatient/outpatient) DFT, both are populated, and PR1 often drives DRG assignment downstream.

DG1 field reference

DG1.1 — Set ID. Sequential starting at 1. The order is meaningful: DG1.1 = 1 with DG1.6 = F (final) typically indicates the principal diagnosis.
DG1.2 — Diagnosis Coding Method. I10 for ICD-10-CM, I9 for ICD-9-CM (legacy), SNM3 for SNOMED.
DG1.3 — Diagnosis Code. The actual code with description, as a CE/CWE.
DG1.4 — Diagnosis Description. Free text; often redundant with DG1.3.2.
DG1.5 — Diagnosis Date. When the diagnosis was established.
DG1.6 — Diagnosis Type. A (admitting), W (working), F (final), ad-hoc codes for principal vs secondary.
DG1.15 — Diagnosis Priority. Numeric ordering; 1 = principal.
DG1.16 — Diagnosing Clinician. The provider who assigned the diagnosis.
DG1.19 — Attestation Date/Time. When the provider signed/attested the diagnosis.

Professional DFT with DG1 stack

MSH|^~\&|ATHENA|CLINIC|WAYSTAR|RCM|20260421141200||DFT^P03|MSG00215|P|2.5
EVN|P03|20260421141200
PID|1||MRN56789^^^CLINIC^MR||ANDERSON^ROBERT^C||19551120|M|||22 ELM ST^^CAMBRIDGE^MA^02138||6175557788|||W||ACCT445566
PV1|1|O|FM-CLINIC^^^CLINIC||||4455667788^NGUYEN^LINH^T^^^MD|||FAM|||||||||||||||||||||||||||||||20260421140000
FT1|1|ENC2026042100045|BATCH-042126|20260421|20260421|CG|99214^OFFICE VISIT LEVEL 4 ESTAB^CPT|||1|185.00|||FM-CLINIC||E11.9^T2DM^I10||4455667788^NGUYEN^LINH^T^^^MD
FT1|2|ENC2026042100046|BATCH-042126|20260421|20260421|CG|36415^VENIPUNCTURE^CPT|||1|12.00|||FM-CLINIC||E11.9^T2DM^I10||4455667788^NGUYEN^LINH^T^^^MD
DG1|1|I10|E11.9^T2DM W/O COMPLICATIONS^I10||20260421|F|||||||1|4455667788^NGUYEN^LINH^T^^^MD
DG1|2|I10|I10.^ESSENTIAL HYPERTENSION^I10||20260421|F|||||||2|4455667788^NGUYEN^LINH^T^^^MD
DG1|3|I10|E78.5^HYPERLIPIDEMIA^I10||20260421|F|||||||3|4455667788^NGUYEN^LINH^T^^^MD
GT1|1||ANDERSON^ROBERT^C||22 ELM ST^^CAMBRIDGE^MA^02138||6175557788||19551120|M|P|SELF|123-45-6789
IN1|1|AETNA001|AETNA|AETNA||||GRP22445||||||||ANDERSON^ROBERT^C|SELF|19551120|22 ELM ST^^CAMBRIDGE^MA^02138||||||||||||||||W12345678901
IN2|1||123-45-6789

Institutional DFT with PR1 for DRG grouping

PR1|1||ICD10PCS|0SRC0J9^RESURFACE RIGHT KNEE JOINT SYNTHETIC SUBSTITUTE^ICD10PCS|TOTAL KNEE REPLACEMENT|20260421100000|01|9876543210^CHEN^DAVID^H^^^MD||||||
PR1|2||ICD10PCS|4A023N8^MEASUREMENT OF CARDIAC OUTPUT^ICD10PCS|INTRAOP MONITORING|20260421090000|02|5544332211^PATEL^ANIL^R^^^MD

Linking charges to diagnoses: FT1.19 carries the diagnosis code for a charge, which downstream systems match against the DG1 stack to build the 837 Loop 2300 CLM segment and its 2410 SV1 service lines with correct HI (diagnosis pointer) references.

6. IN1, IN2, and GT1 — Insurance and Guarantor

The guarantor (GT1) is the person financially responsible for the bill. The insurance (IN1/IN2/IN3) identifies the plans that should be billed. A DFT typically carries one GT1 and one to three IN1 triplets (primary, secondary, tertiary coverage).

GT1 field reference

GT1.2 — Guarantor Number. Internal guarantor ID.
GT1.3 — Guarantor Name. Format: last^first^middle.
GT1.5 — Guarantor Address.
GT1.6 — Guarantor Phone.
GT1.8 — Guarantor Date of Birth.
GT1.9 — Guarantor Sex.
GT1.10 — Guarantor Type. Commonly SELF or P (parent/spouse).
GT1.11 — Guarantor Relationship. Relationship to patient.
GT1.12 — Guarantor SSN. Required for many payer flows.

IN1 field reference

IN1.1 — Set ID. 1 = primary, 2 = secondary, 3 = tertiary.
IN1.2 — Insurance Plan ID. Your internal plan code.
IN1.3 — Insurance Company ID. Payer ID used in EDI (e.g., 60054 for Aetna).
IN1.4 — Insurance Company Name.
IN1.8 — Group Number.
IN1.16 — Name of Insured. Subscriber name, may differ from patient (dependent coverage).
IN1.17 — Insured's Relationship to Patient. SELF, SPOUSE, CHILD, OTHER.
IN1.18 — Insured's DOB.
IN1.36 — Policy Number. The member ID / subscriber ID. Critical for claim submission.

Primary + secondary coverage sample

GT1|1|GTR-98765|SMITH^JOHN^A||123 MAIN ST^^BOSTON^MA^02115||6175551212||19780412|M|P|SELF|123-45-6789
IN1|1|BCBSMA01|60054|BLUE CROSS BLUE SHIELD MA||||GRP99887|BCBSMA STANDARD PPO||||20260101||||SMITH^JOHN^A|SELF|19780412|123 MAIN ST^^BOSTON^MA^02115||||||||||||||||JAQ123456789
IN2|1||123-45-6789|EMP001|ACME CORP|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||SMITH^JANE^M||19800519|SPOUSE
IN1|2|AETNA02|60054|AETNA||||GRP55443|AETNA CHOICE||||20260101||||SMITH^JANE^M|SPOUSE|19800519|123 MAIN ST^^BOSTON^MA^02115||||||||||||||||W9988776655
IN2|2||987-65-4321

Insurance carry-forward:Most billing systems expect DFTs to carry the current active coverage. They should not assume the IN1 from the most recent ADT is still valid — coverage changes at eligibility boundaries, and sending stale IN1 leads to claim denials with reason code CO-27 ("expenses incurred after coverage terminated"). When in doubt, re-query eligibility at the time of charge capture.

7. PV1 — The Visit Context

PV1 establishes the visit in which the charge occurred. For visit-based charges (which is most of them), downstream billing will not accept a DFT without a PV1.

PV1.2 — Patient Class. I (inpatient), O (outpatient), E (emergency), P (pre-admit), R (recurring), B (obstetrics). Drives bill type selection.
PV1.3 — Assigned Patient Location. Unit/room/bed/facility. Matters for revenue code selection on institutional claims.
PV1.7 — Attending Doctor. NPI required for professional billing.
PV1.8 — Referring Doctor. Important for specialist referrals and some Medicare workflows.
PV1.10 — Hospital Service. Clinical service line (MED, SURG, ICU, OBS, etc.).
PV1.19 — Visit Number / Account Number. The account number under which charges accrue. Must be consistent across every DFT for a visit.
PV1.44 — Admit Date/Time.
PV1.45 — Discharge Date/Time.

Inpatient PV1 sample

PV1|1|I|6EAST^612^02^HOSPITAL^^^R^^||||9876543210^CHEN^DAVID^H^^^MD|5544332211^GENERAL^INTERNIST^^^^MD||SURG|||||||||12345|||||||||||||||||||||||||20260418073000|20260421140000|||4250.00|180.00|3750.00|235.00

8. Hospital vs Professional Billing Patterns

The same DFT structure carries two fundamentally different billing models. Understanding which one a given channel represents determines how you transform and route it.

Professional (837P) patterns

FT1.7 carries CPT/HCPCS directly.
FT1.26 carries modifiers (25, 59, RT, LT, 26, TC).
Rendering provider NPI in FT1.20.
One DG1 per diagnosis; typically 1–4 diagnoses per charge.
PV1.2 is usually O (outpatient) or E (emergency).
PR1 is rarely populated.

Institutional (837I / UB-04) patterns

FT1.7 often carries a local charge code; revenue code in FT1.8 or FT1.13.
CPT/HCPCS in FT1.25 with procedure-specific modifiers in FT1.26.
Attending and operating providers in PV1.7 and PR1.12.
DG1 stack is larger — 5 to 20 diagnoses common for inpatient stays.
PR1 stack carries ICD-10-PCS procedures driving DRG assignment.
PV1.2 is I (inpatient) with PV1.44/45 bounding the stay.
Bill type derived from PV1.2 + PV1.3 + discharge disposition in downstream mapping.

Recognizing which you have

Quick tests from the message content:

PV1.2 = I and multiple PR1 → institutional.
PV1.2 = O, single provider, CPT codes with modifiers in FT1.26 → professional.
Revenue codes in FT1 fields → institutional.
One FT1 per E&M visit level (99212–99215) → professional primary care.

9. DFT to 837/835 Downstream Flow

DFT is the internal transport; 837 is what actually leaves the enterprise. A typical revenue-cycle pipeline looks like:

[Clinical System]
      |  DFT^P03 (one per charge event)
      v
[Mirth Connect] --transform--> [Revenue Cycle / PM System]
                                      |
                                      |  Charge scrubbing, coding review, edits
                                      v
                               [837P / 837I claim]
                                      |
                                      v
                               [Clearinghouse: Waystar, Availity, Change]
                                      |
                                      v
                                   [Payer]
                                      |
                                      v
                                 [835 ERA]
                                      |
                                      v
                               [Mirth] --transform--> [Clinical / GL]

The DFT-to-837 mapping is typically handled by the revenue-cycle platform, not by Mirth. Key mappings to be aware of:

PID → 837 Loop 2010BA (Subscriber) and 2010CA (Patient).
GT1 → 837 Loop 2010BA when guarantor is subscriber.
IN1/IN2 → 837 Loop 2000B (Subscriber) with SBR segment carrying coordination of benefits.
DG1 → 837 Loop 2300 HI segment (health care diagnosis codes).
PR1 → 837I Loop 2300 HI (principal and other procedure codes).
FT1 → 837 Loop 2400 (Service Line) — SV1 for 837P, SV2 for 837I.
PV1 → 837 Loop 2300 CLM with CLM05 (facility code / place of service).

835 ERA posting back

When the payer pays, an 835 ERA arrives. The revenue-cycle platform typically posts payments internally and fires a new DFT^P03 with transaction type PY back into the EHR so clinical users see an up-to-date balance. This is your inbound DFT payment channel — often lower volume but critical for patient financial experience.

10. Mirth Connect DFT Channel Patterns

The reliable production patterns we deploy for DFT in Mirth Connect:

Pattern 1 — Validator-first pipeline

Because DFT errors directly cost revenue, we put validation before any transformation. Source channel receives via MLLP, runs a strict validator, and either forwards to the transformer or queues the message in a "DFT-invalid" holding channel with an alert.

// DFT source channel — preprocessor validation
var msg = new XML(connectorMessage.getTransformedData());
var ns = new Namespace('urn:hl7-org:v2xml');

// 1. Required segments present?
var hasPID = msg..ns::PID.length() > 0;
var hasFT1 = msg..ns::FT1.length() > 0;
if (!hasPID || !hasFT1) {
  throw 'DFT missing required segment (PID or FT1)';
}

// 2. Trigger event supported?
var trigger = msg..ns::MSH['MSH.9']['MSH.9.2'].toString();
if (trigger !== 'P03' && trigger !== 'P11') {
  throw 'Unsupported DFT trigger: ' + trigger;
}

// 3. Transaction type valid?
for each (var ft1 in msg..ns::FT1) {
  var txType = ft1['FT1.6'].toString();
  if (['CG','PY','AJ','CR'].indexOf(txType) < 0) {
    throw 'Invalid FT1.6 transaction type: ' + txType;
  }
}

return msg;

Pattern 2 — Charge-master lookup

Validate each CPT code in FT1.7 against a cached charge master (typically loaded nightly from a database) before forwarding. Unknown codes go to a reject queue for coder review.

// Transformer — charge-master validation
var cptCode = msg..ns::FT1[0]['FT1.7']['FT1.7.1'].toString();
var row = $g('cptCache')[cptCode];
if (!row) {
  channelMap.put('REJECT_REASON', 'Unknown CPT: ' + cptCode);
  destinationSet.removeAll();
  destinationSet.add('reject-queue');
  return;
}

// Sanity-check amount against charge master
var amount = parseFloat(msg..ns::FT1[0]['FT1.11']['FT1.11.1'].toString());
if (amount > row.maxAmount * 1.5) {
  logger.warn('Charge amount ' + amount + ' exceeds charge-master max for ' + cptCode);
}

Pattern 3 — Dual-path routing (pro vs institutional)

Route DFTs to different downstream systems based on PV1.2. Inpatient and emergency visits feed institutional billing; outpatient visits feed professional billing.

var patientClass = msg..ns::PV1[0]['PV1.2'].toString();
if (patientClass === 'I' || patientClass === 'E') {
  destinationSet.removeAll();
  destinationSet.add('institutional-billing');
} else {
  destinationSet.removeAll();
  destinationSet.add('professional-billing');
}

Pattern 4 — Void linkage enforcement

Every DFT^P11 (or CR reversal) must reference the original transaction. If it doesn't, reject it rather than forwarding — an unlinked void is an invitation to a reconciliation nightmare.

Pattern 5 — Reconciliation reports

Schedule a daily job that counts DFTs received on each source channel vs acknowledged by the destination and flags any delta. Silent DFT loss is the single most expensive failure mode in this space, and counting-based monitoring catches it faster than alerting on individual message failures.

For the complete Mirth Connect implementation pattern library, see our Mirth Connect guide and the Mirth Connect issues and fixes catalog.

11. Common DFT Pitfalls and How to Avoid Them

The top ten DFT mistakes we find on audits, in order of how much revenue they bleed:

1. Missing account number consistency

PID.18 and PV1.19 must match across every DFT for a visit. When they drift (common when the sending system has its own internal account number scheme different from the billing system's), charges land on orphan accounts and go uncollected.

2. Unlinked diagnosis pointers

FT1.19 left blank while DG1 segments are present. Downstream scrubbing fails because the claim needs to know which diagnosis justifies each charge. Either populate FT1.19 or have a documented default rule (e.g., "first DG1 with DG1.6=F").

3. CPT mismatch between EHR and charge master

The EHR sends a CPT code that doesn't exist in the billing system's charge master (typo, annual CPT update not propagated, local code confused with CPT). The DFT is silently rejected at the downstream side. Mirth-side charge-master validation catches this early.

4. Missing modifiers

Radiology charges without 26 (professional) or TC (technical) component modifiers cause the claim to be billed incorrectly — either double-billed or missing a legitimate component. Surgery without RT/LT laterality modifiers triggers payer edits.

5. Wrong transaction date

FT1.4 set to the message-send timestamp rather than the date of service. This causes timely-filing denials (service dates that appear in the future or before the coverage effective date) and incorrect cost-reporting on institutional claims.

6. Voids without references

DFT^P11 or CR-type DFT^P03 sent without reference to the original transaction. The receiving billing system cannot locate the charge to reverse and silently rejects it. The clinical side still shows the charge as voided; the billing side still shows it as outstanding.

7. Stale insurance

IN1 populated from the most recent ADT rather than current active coverage. When coverage has changed since admit, claims go to the wrong payer and come back denied. Re-query eligibility at charge capture for coverage-sensitive service lines.

8. Rendering vs ordering provider confusion

Lab and imaging charges should identify the rendering provider (the one who read/performed the study), not the ordering provider. Swapping them causes provider-credentialing denials and incorrectly credits the wrong physician for the RVU.

9. Silent duplicate charges

A retry after a transient error produces a second DFT with the same FT1.2 transaction ID. Without explicit idempotency handling on the receiver, the charge is posted twice. FT1.2 should be unique and the receiver should enforce idempotency.

10. Character encoding drift

Patient names with diacritics (García, O'Connor, Müller) arriving mangled because the sender uses UTF-8 and receiver assumes ASCII/Latin-1. Causes name-matching failures between the DFT and the patient master, which in turn causes account-lookup failures. Always declare the charset in MSH.18.

For a broader catalog of HL7 integration failure modes and how to instrument against them, see common HL7 integration errors and our HL7 v2 vs v3 vs FHIR comparison.

DFT operational checklist

✓Confirm the trigger event is P03 (post) or P11 (void) before routing — they are not interchangeable
✓Validate every FT1.6 charge code against the current fee schedule before downstream billing
✓Require at least one DG1 for every clinical encounter charge — unlinked charges block claim scrubbing
✓Link CPT codes in FT1 to ICD-10 codes in DG1 through FT1.26 or DG1.19 relationships
✓Capture guarantor (GT1) before insurance (IN1) — the self-pay fallback depends on it
✓Preserve account number in PID.18 and PV1.19 consistently across every DFT for a visit
✓Honor the sending facility's charge master — do not silently remap CPT codes downstream
✓Alert on FT1.7 transaction amounts that exceed charge-master maximums (likely data errors)
✓Log every P11 void with the original P03 message ID — auditors will ask for the linkage
✓Monitor DFT queue depth and age — billing backlogs show up here first

12. Frequently Asked Questions

What does DFT stand for in HL7?

DFT stands for Detailed Financial Transaction. It is the HL7 v2 message type used to communicate charge, payment, adjustment, and void transactions from a clinical or ADT system to a billing, patient-accounting, or revenue-cycle system.

What is the difference between DFT^P03 and DFT^P11?

DFT^P03 is a post-detail-financial-transaction — it tells the billing system a new charge (or payment/adjustment) has occurred. DFT^P11 is a post-detail-financial-transactions-new-description — it is effectively a void or replacement of a previously posted P03. Not all receivers implement P11; some expect a P03 with a negative FT1.7 amount instead.

Which segments are required in a DFT message?

MSH, EVN, PID, and at least one FT1 are required in virtually every DFT implementation. PV1 is required when the charge is tied to a visit. DG1, PR1, IN1, IN2, and GT1 are required by most US revenue-cycle flows even when the HL7 standard marks them optional, because downstream 837 claim generation depends on them.

Where does the CPT code go in a DFT message?

The CPT (or HCPCS) code typically goes in FT1.7 (transaction code) as a CE/CWE data type, with the coding system identifier indicating CPT4 or HCPCS. Some implementations put CPT in FT1.25 (procedure code) instead; always confirm with the receiving system's specification.

Where does the ICD-10 code go in a DFT message?

ICD-10 diagnoses go in DG1.3 (diagnosis code) with the coding system identifier set to I10 (or ICD10 in older profiles). Each DG1 is one diagnosis; most DFTs carry between one and ten DG1 segments ordered by DG1.1 (set ID) with DG1.6 indicating which is principal.

Does DFT carry insurance information?

Yes — IN1 carries the insurance plan, IN2 carries additional insurance demographics, and GT1 carries the guarantor (the person financially responsible). Most revenue-cycle receivers require all three when the patient has coverage, and GT1 alone when the patient is self-pay.

How does DFT relate to the 837 professional and institutional claims?

DFT is the internal HL7 v2 message that carries charge and demographic data between systems inside the enterprise. The 837P (professional) and 837I (institutional) are the X12 EDI claim transactions sent to payers. A billing system typically consumes DFTs, applies charge-capture rules, and generates 837s for outbound claim submission.

Can Mirth Connect generate 837 from DFT directly?

Technically yes — Mirth can emit X12 with some JavaScript work — but most implementations send DFT into a dedicated revenue-cycle or clearinghouse platform (Epic Resolute, Cerner Revenue Cycle, Waystar, Availity) which handles 837 generation with all its edits. Mirth is the transport and transformation layer, not the claim scrubber.

What is the difference between a hospital DFT and a professional DFT?

Hospital (institutional) DFTs typically carry revenue codes, bill types, UB-04 codes, and DRG-related groupings — designed to feed 837I. Professional DFTs carry CPT/HCPCS codes, modifiers, and NPI-based rendering providers — designed to feed 837P. The segments are the same but the content conventions differ significantly.

How do I handle charge corrections without a DFT^P11?

If the receiver does not support P11, the standard pattern is to send a second DFT^P03 with a negative FT1.7 transaction amount that cancels the original charge, followed by a new DFT^P03 with the corrected charge. Always include the original transaction reference in FT1.9 or FT1.10 for traceability.

HL7 DFT Billing Messages:P03, P11, FT1, DG1, and the Charge-Capture Playbook

Table of Contents