The MOC (Money and Charge Code) data type was introduced in HL7 v2.4 to bind a monetary amount to the specific billing code that the amount is being charged under. It avoids the older pattern of carrying the amount in one field and the CPT/HCPCS code in another unrelated field by combining the two into a single composite. MOC appears in patient-charge segments and, in specialized US-payer profiles, occasionally in FT1 financial transactions.
Purpose
A monetary amount in a healthcare message is rarely meaningful on its own — 150.00 USD could be a copay, a deductible, an office-visit charge, or a lab fee. MOC exists to pair that amount with the coded reason for the charge so receivers can categorise it without inference. The first component is a full MO (nested NM quantity plus ISO 4217 currency); the second is a CWE carrying a code from a published code system such as CPT, HCPCS, ICD-10-PCS, or a local chargemaster identifier.
Components
Source: HAPI HL7v2 v2.8.1 javadoc (MOC).
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| MOC.1 | Monetary Amount | mo | — | O | Nested MO: NM quantity plus ISO 4217 currency code (HL7 table 0913). |
| MOC.2 | Charge Code | cwe | — | O | Coded billing identifier — CPT, HCPCS, ICD-10-PCS, or local chargemaster code. |
Most-used components
- MOC.1 Monetary Amount — the dollar/euro charge itself, expressed as a full MO so the currency travels with the number.
- MOC.2 Charge Code — the CPT/HCPCS or local chargemaster code that justifies the amount; the component most often left empty by senders that treat MOC as if it were plain MO.
Where it's used
- FT1-related extensions in DFT^P03 financial-transaction messages, where MOC pairs the transaction amount with the procedure code.
- BLG-2 Charge Type binding in profiles that need both an amount and a chargemaster code on the same field.
- Patient charge custom segments where the chargemaster system emits one MOC per line item.
- PR1 procedure-cost extensions that attach cost to the CPT/ICD-10-PCS already present on the segment.
- IN2 cost-share extensions for benefit-level charges in some US-payer implementations.
- Z-segments used by chargemaster export interfaces and revenue-cycle bridges.
Version differences
- HL7 v2.4 — MOC introduced with the two-component Monetary Amount + Charge Code layout.
- HL7 v2.5 through v2.8 — no structural changes; the inner MO and CWE evolved (CWE table bindings tightened) but MOC's shape held.
- HL7 v2.8.1 — HAPI javadoc confirms the two-component definition; MOC.1's nested MO.2 explicitly binds to HL7 table 0913.
- HL7 v2.8.2 — no structural changes.
Common mistakes
- Putting the CPT code in MOC.1 — MOC.1 is an MO (a number plus a currency), not a code; the CPT belongs in MOC.2's CWE.1.
- Omitting the currency inside MOC.1 — the nested MO.2 still applies;
150.00^^99213^Office Visit^CPTis ambiguous on currency. - Sending the chargemaster code without a coding system in MOC.2.3 — receivers that match on (code, system) will not be able to distinguish CPT
99213from a local code that happens to collide. - Treating MOC as interchangeable with plain MO — populating only MOC.1 leaves the message looking valid but throws away the reason-for-charge that MOC exists to carry.
- Using display text in MOC.2.1 instead of the actual code (
Office Visitinstead of99213) — CWE.1 is the identifier; CWE.2 is the display string.
Examples
Minimal value — CPT 99213 office visit at $150 USD:
150.00^USD^99213^Office Visit Level 3^CPT
Multi-component value — HCPCS J-code for an injectable, with cents:
245.75^USD^J1745^Infliximab injection 10 mg^HCPCS
Fully populated edge case — local chargemaster code with explicit system OID:
89.40^USD^CHG-LAB-CBC^CBC with differential^99CHGMSTR^^^2.16.840.1.113883.3.4567.8
In context — FT1 financial-transaction line where MOC carries the charge plus its CPT code in a profile that binds MOC to FT1-22:
FT1|1|TX-0091|CG-1442|20260610|20260610|CG|99213^Office visit established^CPT|||1|||||||||||||150.00^USD^99213^Office Visit Level 3^CPT
Common pitfall — CPT code put in the MO.1 slot:
99213^USD^150.00^Office Visit^CPT <- WRONG; MOC.1 must be a numeric amount
150.00^USD^99213^Office Visit^CPT <- CORRECT
FHIR mapping
The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for MOC. Conceptually MOC maps to a pairing of FHIR's Money data type and a coded reference on a charge resource:
| MOC component | FHIR target |
|---|---|
| MOC.1 Monetary Amount → MO.1 | Money.value on ChargeItem.priceOverride or Invoice.lineItem.priceComponent.amount.value |
| MOC.1 Monetary Amount → MO.2 | Money.currency (ISO 4217 alpha-3) |
| MOC.2 Charge Code | ChargeItem.code (CodeableConcept) or Invoice.lineItem.chargeItemCodeableConcept |
The split mirrors how FHIR separates the financial value from the billable concept — the amount and the code are different resource attributes, even though HL7 v2 bundles them into a single composite.
Engine considerations
- Currency validation: MOC.1's inner MO.2 must validate against ISO 4217 (HL7 table 0913); engines that only check MO at top-level fields will miss nested MOs inside MOC.
- Coding-system fidelity: MOC.2.3 is the coding system; engines that strip CWE.3 lose the difference between CPT, HCPCS, ICD-10-PCS, and local codes — and downstream payers reject silently on system mismatch.
- BigDecimal precision: the inner MO.1 carries cents (or minor units); never round through
double. - Round-trip with chargemaster systems: many US chargemaster exports use local codes in MOC.2 — preserve the coding system identifier (often a 99-prefixed local table or an OID) verbatim.
- Display-text drift: MOC.2.2 (display) is informational; never make routing decisions on the display string. Match on (code, system) only.
How Vorro parses and produces MOC
On inbound, Vorro parses MOC.1 as a full MO — BigDecimal for the quantity and an ISO 4217 alpha-3 code for the currency, both round-tripped without locale coercion. MOC.2 is parsed as a full CWE; the (code, system) pair is the routing key, the display string is captured but never used for matching. Vorro validates known chargemaster systems (CPT, HCPCS, ICD-10-PCS, the LOINC subset used for lab charges) against in-process tables and routes unknown systems — including site-local 99-prefixed codes — to a curation queue with provenance preserved.
On outbound, Vorro always emits both components. MOC.1 carries the full amount-plus-currency MO; MOC.2 carries the chargemaster code with an explicit system identifier (CPT, HCPCS, or an OID for local systems) so downstream payers and revenue-cycle systems can match on (code, system) without inference. Display text is populated when available but treated as non-authoritative.
