HL7 MFN_M04 (Charge Description Master File) | Integration Soup HL7 Reference Guide

HL7 MFN_M04 Charge Description Master File

The master-file feed for keeping charge codes and basic billing metadata aligned.

HL7 message structure MFN_M04 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
MFI	Master File Identification	Yes	No
MFN_M04.MF_CDM	Mf Cdm group	Yes	Yes
MFE	Master File Entry	Yes	No
CDM	Charge Description Master	Yes	No
PRC	Pricing	No	Yes

MFN_M04 publishes changes to a charge description master. In day-to-day interface work, that usually means the billing or patient accounting system owns a list of chargeable items, and departmental systems need enough of that list to post charges using valid local codes.

Do not confuse this message with a patient charge transaction. DFT_P03 says "charge this patient account." MFN_M04 says "this is a chargeable item and here is the catalog metadata the receiver should know before it ever sends or consumes a charge."

A small MFN M04 example

MSH|^~\&|BILLING|CITYHOSP|EHR|CITYHOSP|20260722100000||MFN^M04^MFN_M04|MFN040001|P|2.5.1 MFI|CDM^Charge description master^HL70175|BILLING^CITYHOSP|UPD|20260722100000|20260722103000|AL MFE|MAD|MFN040001|20260722103000|LABGLU^Glucose serum charge^L|CE CDM|LABGLU^Glucose serum charge^L|GLU^Glucose^L|Glucose Serum|Serum glucose laboratory charge|||82947^Glucose quantitative^CPT|A PRC|LABGLU^Glucose serum charge^L|CITYHOSP^City Hospital^L|LAB^Laboratory^L|O|45.00^USD|STANDARD

What workflow it represents

The sender is normally patient accounting, an enterprise charge master system, or an integration layer that manages charge-code publishing. Receivers include departmental systems, order/result systems, and engines that translate local service codes into billing events.

The practical goal is boring in the best possible way: everyone agrees on the same charge code before a clinical workflow reaches billing. If a lab system posts a glucose charge code that patient accounting no longer recognizes, the later patient-account message becomes a cleanup problem instead of a clean transaction.

How to read the structure

MSH identifies the MFN M04 notification. MFI identifies the master file as the charge description master and carries the file-level action and timing.

Each MF_CDM group starts with MFE, whose primary key should match the charge item being changed. CDM carries the charge description record. PRC can repeat when pricing varies by facility, department, patient class, effective date, or other local billing rules.

When the receiver supports application acknowledgments, expect MFK_M01 to report whether records were accepted. For a charge master, record-level status is more useful than a cheerful message-level ACK that hides one failed code.

Implementation traps

The first trap is treating CDM as a complete claims or reimbursement model. It is a charge catalog record, not the whole revenue-cycle rulebook. Contract rules, payer behavior, insurance profiles, modifiers, and account-specific billing rules usually live somewhere else.

The second trap is assuming one price per code. PRC repeats for a reason. A receiver may need to distinguish outpatient from inpatient, one facility from another, or current pricing from future-effective pricing.

Also agree what inactive means. Some receivers should stop presenting the item immediately; others must keep accepting old charges for corrections or late postings. The interface spec should say which behavior is expected.

Reference notes

HL7 master-file material identifies M04 as the charge description event and describes the MFN pattern as MFI plus repeating MFE-led master-file records. The MFN_M04 structure uses the required CDM segment for the charge record, with optional repeating PRC segments for pricing detail.