HL7 for billing and DFT

Billing interfaces are less forgiving than they look because every duplicate and correction has a financial consequence.

HL7 billing feeds most often mean DFT_P03: a detailed financial transaction. The clinical event may have happened in radiology, lab, pharmacy, clinic, or the emergency department, but the billing receiver cares about charge identity, patient account, diagnosis, procedure, provider, service date, payer context, and whether the transaction is a charge, correction, or reversal.

The core segment is FT1. It should not be treated as just another result row. If a DFT interface creates duplicate charges or loses corrections, the problem becomes financial reconciliation, not just HL7 troubleshooting.

MSH|^~\&|EHR|CITYHOSP|BILLING|CITYHOSP|20260715133000||DFT^P03^DFT_P03|DFT000501|P|2.5.1 EVN|P03|20260715133000 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|O|RAD^CHG^1^CITYHOSP||||12345^Careful^Clara^^^^^^NPI|||||||||||VN000345^^^CITYHOSP^VN FT1|1|CHG7788|20260715132500|20260715132500|CG|71045^Chest X-ray single view^CPT|1|1|125.00|125.00|||||12345^Careful^Clara^^^^^^NPI DG1|1||R07.9^Chest pain, unspecified^I10|||A PR1|1||71045^Chest X-ray single view^CPT||||||12345^Careful^Clara^^^^^^NPI IN1|1|PLAN-A|INS001|City Health Plan

This is synthetic sample data for learning and testing. Open it in HL7 Soup Web before mapping it so the segment groups, repeated fields, and coded values are visible.

Know The Charge Grain

Agree whether each FT1 is one billable service, one item line, one procedure, one medication dispense, one visit-level fee, or a local accounting transaction. Then test repeats. Many DFT messages carry multiple FT1 segments, and downstream systems may deduplicate using transaction ID, order number, procedure code, date, account, or a local combination.

Be very clear about correction behavior. Some senders reverse a charge with a negative amount. Some send a cancellation. Some send a new transaction that supersedes the old one. HL7 will parse all of them; only the implementation agreement tells you which behavior is financially correct.

  • Keep FT1-2 transaction ID stable and visible.
  • Preserve service date/time and posting date separately when both are present.
  • Do not strip provider, diagnosis, procedure, or insurance context if billing needs it.

When a billing workflow creates DFT from CSV, SQL, or another source, build the repeat deliberately. Loop over the source charge lines and append one FT1 per line, while keeping patient, visit, account, provider, and diagnosis context attached to the message or repeated where the receiver expects it. The repeating OBX tutorial is not a billing tutorial, but the Integration Soup looping idea is the same: put the repeated business object inside the loop and keep shared context outside it.

Diagnosis, Procedure, And Insurance Context

DG1, PR1, IN1, GT1, and PV1 fields can all matter. A billing feed that only sends FT1 may be enough for a tightly integrated patient-accounting system, but it is not enough for every claims, analytics, or charge-capture receiver.

A Practical Integration Soup Workflow

In Integration Soup, log DFT message control ID, patient account, visit number, FT1 transaction ID, transaction type, procedure code, amount, and destination. Route charges and reversals separately when the downstream system expects different behavior.

If charges arrive as files, use the file-processing best-practices tutorial. For reconciliation extracts, the HL7 to CSV tutorial gives a practical pattern for making finance-readable rows without hiding the raw HL7.

The Test Pack I Would Ask For

Ask for a simple charge, multiple FT1s in one message, a corrected charge, a reversed charge, a duplicate resend, missing insurance, changed diagnosis, late charge after discharge, and an ACK or downstream rejection example.