HL7 MO Data Type: Money

The MO (Money) data type was introduced in HL7 v2.3 to express monetary values without relying on a bare NM field plus an out-of-band currency assumption. MO pairs a numeric amount with an explicit currency denomination drawn from ISO 4217 (HL7 table 0913), so a receiving system never has to guess whether 150.00 means USD, EUR, or GBP. It appears in fields like IN1-37 Patient Amount Due and FT1-22 Transaction Amount.

Purpose

MO exists so that monetary fields carry their currency on the wire. Healthcare messages routinely cross billing systems, payers, and clearinghouses that span jurisdictions; a charge expressed only as a number is ambiguous and a frequent source of integration defects. MO solves this by requiring two components — the quantity and an ISO-4217-aligned currency code — and by treating the currency code as part of the value rather than an assumed default.

Components

Source: HAPI HL7v2 v2.8.1 javadoc (MO).

Comp	Name	Sub-type	Length	Required	Description
MO.1	Quantity	nm	—	O	Numeric amount; decimal, sign-bearing, no currency symbol, no thousands separator.
MO.2	Denomination	id	—	O	ISO 4217 three-letter alphabetic currency code (USD, EUR, GBP, JPY, CAD, AUD…). Bound to HL7 table 0913.

Most-used components

MO.1 Quantity — the dollar/euro/yen amount itself; populated whenever MO is meaningful.
MO.2 Denomination — the ISO 4217 currency code; the component most often omitted and the source of most MO interoperability defects.

Where it's used

IN1-37 Patient Amount Due — eligibility and benefits messages report patient-responsibility balances here.
FT1-22 Transaction Amount — Extended in DFT financial transactions; MO replaces older CP/NM patterns in modern profiles.
BLG-2 / BLG-3 Charge Type / Account ID extensions in some local billing variants that bind MO.
PR1 procedure-cost extensions in regional implementations (Australia, parts of EU).
IN2-78 Patient Member Number balance fields in some profiles.
GP1 grouping-related extensions reporting DRG-level monetary amounts.
Custom Z-segments and Z-fields used by US-payer EDI bridges that prefer MO over CP.

Version differences

HL7 v2.3 — MO introduced with the two-component Quantity + Denomination layout.
HL7 v2.4 through v2.8.1 — no structural changes; HAPI v2.8.1 javadoc confirms the two-component definition.
HL7 v2.8.1 — MO.2 explicitly bound to HL7 table 0913 (ISO 4217 currency codes).
HL7 v2.8.2 — no structural changes; table 0913 minor refresh only.

Common mistakes

Omitting MO.2 Denomination — downstream systems silently default to USD (or whatever the engine's regional setting prefers), producing wrong amounts in cross-border exchanges.
Including a currency symbol in MO.1 (e.g. $150.00 or €150) — MO.1 is NM and must be a bare decimal; symbols belong in MO.2 as a code, not as glyphs.
Using a non-ISO-4217 code in MO.2 (US instead of USD, EU instead of EUR) — HL7 table 0913 is strictly aligned to ISO 4217 alpha-3.
Sending thousands separators in MO.1 (1,500.00) — NM is locale-independent and must use . for the decimal mark and no grouping separator.
Encoding negative amounts as (150.00) instead of -150.00 — accounting parentheses are a presentation convention and are not valid NM syntax.

Examples

Minimal value (USD $100):

100^USD

Multi-component value with cents:

150.50^USD

Fully populated edge case — refund (negative amount) in EUR:

-42.75^EUR

JPY without decimals (yen does not subdivide):

12500^JPY

In context — IN1-37 Patient Amount Due in a verification response:

IN1|1|BCBS001|BCBS^Blue Cross^L|Blue Cross Blue Shield|PO Box 33||5551234567|GRP9988||||20260101|20261231|||TESTPATIENT^ALEX^Q|SE^Self^HL70063|19720508|123 Main^^Anytown^MO^65000||||1|||||||||||||150.50^USD

In context — FT1-22 Transaction Amount in a DFT^P03 charge:

FT1|1|TX-0091|CG-1442|20260610|20260610|CG|99213^Office visit established^CPT|||1|||||||||||||245.00^USD

Common pitfall — currency symbol in MO.1:

IN1|1|...|$150.50^USD              <- WRONG; MO.1 must be NM
IN1|1|...|150.50^USD               <- CORRECT

FHIR mapping

The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for MO. Conceptually MO maps to the FHIR Money data type:

MO.1 Quantity → Money.value (decimal).
MO.2 Denomination → Money.currency (code bound to ISO 4217 alpha-3 in FHIR's required value set).

When MO appears inside a larger composite that itself has a published mapping (for example, IN1-37 → Coverage.costToBeneficiary.value), the two MO components are typically split across Money.value and Money.currency of that target element.

Engine considerations

Currency validation: receivers should validate MO.2 against the ISO 4217 alpha-3 set (HL7 table 0913) and reject unknown codes rather than coercing them — GBP vs GB is a one-character mistake with three-order-of-magnitude consequences.
Locale-independent decimal: MO.1 inherits NM's strict . decimal mark; Java engines using NumberFormat.getInstance() will silently localise — always use Locale.ROOT.
Currency-precision awareness: ISO 4217 defines minor-unit exponents per currency (USD/EUR = 2, JPY = 0, BHD = 3). Engines that hard-code two decimal places truncate or pad incorrectly across currencies.
Negative-amount conventions: HL7 NM uses leading -; accounting-style parentheses must be converted before serialising.
Round-tripping with FHIR Money: FHIR's Money.value is decimal and does not allow scientific notation; MO.1 likewise must be plain decimal on the wire.

How Vorro parses and produces MO

On inbound, Vorro parses MO.1 with BigDecimal (no doubles — financial precision is non-negotiable) and Locale.ROOT. MO.2 is validated against an embedded ISO 4217 table and round-tripped verbatim; unknown codes are routed to a curation queue rather than coerced to a regional default. Where the inbound source omits MO.2, Vorro applies the explicitly configured per-connection currency default and tags the resulting record with a provenance note so downstream consumers can see that the currency was inferred.

On outbound, Vorro always emits MO with both components populated — MO.1 as a BigDecimal formatted with the correct minor-unit precision for the chosen currency, and MO.2 as the alpha-3 ISO 4217 code. Symbols ($, €, ¥) are never written into MO.1.

Sources

← Back to HL7 v2 Guide