The BLG (Billing) segment carries billing instructions attached to an order. It tells the receiver when a charge for the order should be generated, how the charge should be classified, and which account it should be posted against. Unlike CDM and PRC, which describe reference pricing, BLG conveys the billing intent for a specific ordered service at the time the order is placed.
The BLG segment is small but consequential: it is the place where an order says "bill this, this way, to this account." Its key fields are When to Charge (BLG-1), Charge Type (BLG-2), and Account ID (BLG-3).
Purpose
The BLG segment exists to attach billing direction to an order. It does the following:
- States when the charge should be generated relative to the order lifecycle.
- Classifies the charge by type so the billing system applies the correct handling.
- Identifies the account to which the charge should be posted.
- Optionally records the reason for the charge type.
BLG does not carry the charge amount itself — pricing is resolved downstream from the charge master. It carries the instructions that govern how and when the order becomes a billable event.
Used in
BLG (Billing) carries order-level billing instructions in ORM order messages. Within an ORM, the BLG segment is part of the order group and follows the ORC (Common Order) and the order-detail segments, supplying billing direction for that order. It is optional and appears at most once per order.
Typical placement inside an ORM order group:
- ORC (Common Order)
- OBR or other order-detail segment
- BLG (Billing) — billing instructions for the order
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (BLG). Length —; Required and Table # from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| BLG-1 | When to Charge | ccd | — | O | — | HL70100 | When the charge should be generated |
| BLG-2 | Charge Type | id | — | O | — | HL70122 | Classification of the charge |
| BLG-3 | Account ID | cx | — | O | — | — | Account the charge is posted against |
| BLG-4 | Charge Type Reason | cwe | — | O | — | HL70475 | Reason for the assigned charge type |
Most-used fields
- BLG-1 When to Charge controls the timing of charge generation (for example on order, on result, or at a specified time) and is the field most billing rules key on.
- BLG-2 Charge Type classifies the charge (for example charge, credit, contract) and routes it to the correct billing handling.
- BLG-3 Account ID directs the charge to the right account, which matters when an order could be billed to more than one account.
- BLG-4 Charge Type Reason documents why a particular charge type was chosen and is increasingly used for audit.
Version differences (2.3 to 2.8.2)
- BLG appeared early in the order-entry framework with the first three fields (When to Charge, Charge Type, Account ID) present since HL7 v2.3.
- Charge Type Reason (BLG-4) was added in a later release (v2.5) as billing systems needed to record justification for charge-type assignment; it is present in v2.5.1.
- The When to Charge field uses the composite CCD type, which carries an event code and an associated date/time; this structure is stable across v2.4 through v2.8.2.
- From v2.6 through v2.8.2 the segment retains all four fields in the same order with no deprecations, so the v2.5.1 shape transfers cleanly to later versions.
Common mistakes
- Putting a charge amount in BLG. The segment carries instructions, not money; amounts belong in FT1 or downstream charge records.
- Sending only Charge Type (BLG-2) without When to Charge (BLG-1) and assuming the receiver will default the timing correctly.
- Treating BLG-1 as a simple code. It is a CCD composite and may include a date/time component that must be parsed.
- Posting to the wrong account because Account ID (BLG-3) was omitted and the receiver fell back to a default account.
- Confusing BLG with FT1. BLG attaches billing intent to an order; FT1 transmits the actual financial transaction.
- Assuming BLG repeats — it appears at most once per order in v2.5.1.
Examples
Minimal BLG (charge type only):
BLG||CH
Fully populated BLG:
BLG|O^20260610100000|CH|ACCT-554120^^^MERCYGEN^AN|ROUTINE^Routine order charge^HL70475
Annotated breakdown of the fully populated example:
BLG-1 When to Charge O^20260610100000 (charge on order, at this time)
BLG-2 Charge Type CH (charge)
BLG-3 Account ID ACCT-554120^^^MERCYGEN^AN (patient account number)
BLG-4 Charge Type Reason ROUTINE^Routine order... (reason for the charge type)
In-context excerpt 1 — BLG inside an ORM order group, following ORC and OBR:
MSH|^~&|CPOE|MERCYGEN|LAB|MERCYGEN|20260610100000||ORM^O01^ORM_O01|MSG00712|P|2.5.1
PID|1||MRN778412^^^MERCYGEN^MR||Rivera^Daniela^A||19840312|F
ORC|NW|ORD-99231^CPOE|||||||20260610100000
OBR|1|ORD-99231^CPOE||80053^Comprehensive metabolic panel^CPT|||20260610100000
BLG|O^20260610100000|CH|ACCT-554120^^^MERCYGEN^AN|ROUTINE^Routine order charge^HL70475
In-context excerpt 2 — BLG directing a credit on order cancellation:
ORC|CA|ORD-99231^CPOE|||||||20260610113000
OBR|1|ORD-99231^CPOE||80053^Comprehensive metabolic panel^CPT
BLG|T^20260610113000|CR|ACCT-554120^^^MERCYGEN^AN|CANCEL^Order cancelled^HL70475
FHIR mapping
BLG is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR Implementation Guide for BLG. Conceptually, BLG billing instructions correspond most closely to a combination of FHIR Account and ChargeItem, where Account ID maps to ChargeItem.account or an Account reference, Charge Type informs ChargeItem.code or category, and When to Charge informs ChargeItem.occurrence. Because the published IG does not define a normalized field-by-field mapping for BLG, any such projection is an integration design decision rather than a standard transform.
Engine considerations
- BLG is optional and singular within an order group; engines should not expect it on every order and must not treat its absence as an error.
- The CCD type in BLG-1 carries both an event code and a date/time; configure the engine to parse both components rather than just the leading code.
- Keep BLG bound to its parent ORC during routing so billing intent stays associated with the correct order.
- Validate Charge Type (BLG-2) against HL70122 so charges and credits are not interchanged.
- Because BLG carries no amount, do not attempt to derive financial totals from it — those come from FT1 or charge-master resolution.
How Vorro parses and produces BLG
When consuming an ORM, Vorro attaches each BLG to its parent ORC so billing intent travels with the correct order. When to Charge (BLG-1) is decomposed into its event code and optional timestamp, Charge Type (BLG-2) is validated against the charge-type vocabulary, and Account ID (BLG-3) is normalized so the charge is posted to the intended account. Charge Type Reason is preserved for audit.
When producing BLG, Vorro emits it only when an order carries billing direction, populating When to Charge and Charge Type as the primary instructions and Account ID when the target account is known. The segment is always placed within the order group after the order-detail segments, and no amount is ever written into BLG, keeping the boundary between billing intent (BLG) and financial transactions (FT1) clean.
