The CDM (Charge Description Master) segment defines the static, facility-independent attributes of a single chargeable item in a hospital's charge description master. It carries the data that uniquely identifies the charge, its short and long descriptions, the procedure codes it maps to, and inventory and contract metadata. The pricing detail that varies by facility lives in the companion PRC segment, so a CDM almost always travels together with one or more PRC segments inside the same master-file record.
The CDM segment is the anchor of the charge-master file. Where PRC answers "what does this cost here," CDM answers "what is this charge, and how is it described and coded." Its key fields are Primary Key Value - CDM (CDM-1), Charge Description Short (CDM-3), Charge Description Long (CDM-4), and Procedure Code (CDM-7).
Purpose
The CDM segment exists to transmit the master-file definition of a chargeable service or item so that downstream systems can recognize, describe, and code that charge consistently. It does the following:
- Establishes the primary key for the charge so that PRC and other related records can reference it.
- Carries human-readable short and long descriptions and any alias codes used by other systems.
- Maps the charge to one or more procedure codes and inventory numbers.
- Flags the charge as active or inactive and indicates room-fee and exploding-charge behavior.
CDM never carries patient-specific or encounter-specific data. It is reference data, maintained centrally and synchronized to ancillary, billing, and clinical systems through master-file notification messages.
Used in
CDM (Charge Description Master) carries charge-master data in MFN^M04 master-file notification messages. Within an MFN^M04, each charge-master entry is introduced by an MFE (Master File Entry) segment, and the CDM segment follows to supply the charge definition. One or more PRC (Pricing) segments then follow the CDM to supply facility-specific pricing. The message itself opens with an MFI (Master File Identification) segment identifying the file as a charge-description master.
Typical placement inside the MFN^M04:
- MSH (Message Header)
- MFI (Master File Identification)
- MFE (Master File Entry) — one per charge-master record
- CDM (Charge Description Master) — the charge definition
- PRC (Pricing) — one or more pricing rows for that charge
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (CDM). Length —; Required and Table # from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| CDM-1 | Primary Key Value - CDM | ce | — | R | — | HL70132 | Charge code that uniquely identifies the entry |
| CDM-2 | Charge Code Alias | ce | — | O | Y | — | Alternate charge codes used by other systems |
| CDM-3 | Charge Description Short | st | — | R | — | — | Abbreviated description of the charge |
| CDM-4 | Charge Description Long | st | — | O | — | — | Full text description of the charge |
| CDM-5 | Description Override Indicator | is | — | O | — | HL70268 | Whether description may be overridden locally |
| CDM-6 | Exploding Charges | ce | — | O | Y | — | Component charges generated by this charge |
| CDM-7 | Procedure Code | ce | — | O | Y | HL70088 | Procedure codes associated with the charge |
| CDM-8 | Active/Inactive Flag | id | — | O | — | HL70183 | Whether the charge entry is currently active |
| CDM-9 | Inventory Number | ce | — | O | Y | HL70132 | Inventory item numbers tied to the charge |
| CDM-10 | Resource Load | nm | — | O | — | — | Relative resource consumption value |
| CDM-11 | Contract Number | cx | — | O | Y | — | Contract identifiers governing the charge |
| CDM-12 | Contract Organization | xon | — | O | Y | — | Organizations party to the contract |
| CDM-13 | Room Fee Indicator | id | — | O | — | HL70136 | Whether the charge is a room fee |
Most-used fields
In real-world charge-master interfaces, a handful of CDM fields carry almost all of the weight:
- CDM-1 Primary Key Value - CDM is the charge code and the join key. Every PRC and downstream price row references it, so it must be present and stable across updates.
- CDM-3 Charge Description Short is what appears on most screens, statements, and reports. Receivers frequently truncate to this value.
- CDM-4 Charge Description Long supplies the verbose description used for review and reconciliation.
- CDM-7 Procedure Code links the charge to CPT/HCPCS or local procedure coding, which is essential for claims and clinical mapping.
- CDM-8 Active/Inactive Flag drives whether a receiver retires or retains the charge during synchronization.
Version differences (2.3 to 2.8.2)
- The CDM segment was introduced with the master-file (MFN) framework and has been stable in shape since HL7 v2.3, which already defined the thirteen fields seen here.
- Across v2.3, v2.3.1, v2.4, and v2.5/2.5.1 the field set and sequence are unchanged; refinements were limited to data-type definitions (for example the normalized CE and CX structures) and table references rather than the addition or removal of fields.
- In v2.6 through v2.8.2 the segment continues unchanged in field order. CE-typed fields are commonly represented with CWE in tooling, but the CDM segment definition itself is not restructured.
- No fields have been deprecated or withdrawn across the 2.3 to 2.8.2 range, which makes CDM one of the more durable financial segments for cross-version interfaces.
Common mistakes
- Treating CDM-1 as free text. It is a coded value (CE) and must carry a stable identifier; reusing or renumbering it breaks the link to PRC pricing rows.
- Sending CDM without an accompanying PRC. A charge definition with no pricing row is often rejected or silently dropped by receivers expecting both.
- Confusing CDM-8 with CDM-9. In v2.5.1 CDM-8 is the Active/Inactive Flag and CDM-9 is the Inventory Number; some legacy mappings invert these.
- Populating Charge Description Short (CDM-3) beyond the receiver's display width and relying on the receiver not to truncate.
- Omitting Procedure Code (CDM-7) and then expecting downstream claims systems to derive CPT/HCPCS automatically.
- Sending repeating fields such as Charge Code Alias (CDM-2) with inconsistent coding systems in each repetition.
Examples
Minimal CDM (primary key and short description only):
CDM|10042^Chest X-Ray Single View^L|||CXR 1V
Fully populated CDM:
CDM|10042^Chest X-Ray Single View^L|RAD0042^XR-CHEST^ALT|CXR 1V|Radiology Chest X-Ray, Single Frontal View|N|EXPL77^Film+Read^L|71045^Radiologic exam chest single view^CPT|A|INV5567^X-Ray Film 14x17^L|3.5|CN-2026-118^^^MERCYGEN|7700112^Mercy General Imaging^^^^^XX|N
Annotated breakdown of the fully populated example:
CDM-1 Primary Key Value - CDM 10042^Chest X-Ray Single View^L (charge code, local coding system)
CDM-2 Charge Code Alias RAD0042^XR-CHEST^ALT (alias used by radiology system)
CDM-3 Charge Description Short CXR 1V (short display description)
CDM-4 Charge Description Long Radiology Chest X-Ray, Single... (full description)
CDM-5 Description Override Ind N (no local override allowed)
CDM-6 Exploding Charges EXPL77^Film+Read^L (component charges generated)
CDM-7 Procedure Code 71045^Radiologic exam...^CPT (CPT procedure code)
CDM-8 Active/Inactive Flag A (active charge)
CDM-9 Inventory Number INV5567^X-Ray Film 14x17^L (inventory item)
CDM-10 Resource Load 3.5 (relative resource value)
CDM-11 Contract Number CN-2026-118^^^MERCYGEN (governing contract)
CDM-12 Contract Organization 7700112^Mercy General Imaging... (contracting org)
CDM-13 Room Fee Indicator N (not a room fee)
In-context excerpt 1 — CDM inside an MFN^M04 charge-master notification, following MFI and MFE:
MSH|^~&|CHARGEMASTER|MERCYGEN|BILLING|MERCYGEN|20260610093000||MFN^M04^MFN_M04|MSG00231|P|2.5.1
MFI|CM^Charge Master^HL70175|MERCYGEN|UPD|20260610093000||AL
MFE|MAD|||10042^Chest X-Ray Single View^L|CM
CDM|10042^Chest X-Ray Single View^L|RAD0042^XR-CHEST^ALT|CXR 1V|Radiology Chest X-Ray, Single Frontal View|N||71045^Radiologic exam chest single view^CPT|A|||||N
PRC|10042^Chest X-Ray Single View^L|MERCYGEN^^L|RAD||175.00^USD^^^TP||1|1|||20260101|||N|71045^^CPT|Y|A|62.40|
In-context excerpt 2 — two CDM records in a single MFN^M04 (add and inactivate):
MFE|MAD|||10042^Chest X-Ray Single View^L|CM
CDM|10042^Chest X-Ray Single View^L||CXR 1V|Radiology Chest X-Ray, Single Frontal View|N||71045^Radiologic exam chest single view^CPT|A|||||N
MFE|MDC|||10099^Portable Chest X-Ray^L|CM
CDM|10099^Portable Chest X-Ray^L||CXR PORT|Radiology Chest X-Ray, Portable|N||71045^Radiologic exam chest single view^CPT|I|||||N
FHIR mapping
CDM is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR Implementation Guide for CDM. Conceptually, a CDM charge-master entry corresponds most closely to a FHIR ChargeItemDefinition, where the charge code maps to ChargeItemDefinition.code, the descriptions map to ChargeItemDefinition.title and .description, and the active flag maps to ChargeItemDefinition.status. Because the published IG does not define a normalized field-by-field mapping for CDM, any such projection is an integration design decision rather than a standard transform.
Engine considerations
- Most interface engines treat CDM as a Z-aware standard segment; confirm the engine's v2.5.1 schema includes CDM so that fields beyond CDM-4 are not silently dropped.
- Repeating fields (CDM-2, CDM-6, CDM-7, CDM-9, CDM-11, CDM-12) must be parsed with repetition (
~) handling enabled; flattening them to a single value loses data. - CDM rarely arrives alone — engines should preserve segment grouping so the CDM stays bound to its MFE and following PRC segments during routing and transformation.
- Because CDM-1 is the join key for pricing, normalize its coding system and value before keying any internal charge-master table.
- Validate CDM-8 against an active/inactive vocabulary so inactivations are honored rather than treated as additions.
How Vorro parses and produces CDM
When consuming an MFN^M04, Vorro keys each charge-master record on the normalized CDM-1 Primary Key Value - CDM and binds the CDM to its preceding MFE action code (add, update, deactivate) and to the PRC rows that follow it within the same record group. Repeating fields are preserved as ordered lists rather than collapsed, so alias codes and procedure codes survive round-trips. Descriptions are carried through verbatim, with optional length normalization applied only when a downstream receiver advertises a narrower display width.
When producing CDM, Vorro emits CDM-1, CDM-3, and the active/inactive flag as required anchors, populates Procedure Code and Inventory Number from the source charge record when present, and suppresses empty trailing fields. The CDM is always emitted in the correct MFE/CDM/PRC order so receivers that rely on segment grouping parse the charge definition and its pricing as a unit.
