HL7 Table HL70032: Charge/Price Indicator

HL70032 is a small user-defined v2 table whose values describe how a particular patient visit is being priced — full charges, a contract rate, a flat fee, a reduced amount, an insurance-claim setup, or a constant price. It is carried almost exclusively in PV1-21 Charge Price Indicator, where it tells downstream billing and claims systems which fee schedule to apply when an encounter is finalized.

Purpose

PV1-21 exists because the same hospital encounter can be billed under very different arrangements depending on the patient's payer, employer contract, or self-pay status. HL70032 lets the registration system stamp that arrangement onto the visit at admit time, so the charge-capture and claims systems downstream do not have to re-derive it from coverage data. The codes are short — two-character mnemonics drawn from the IS data type — and they describe the pricing posture, not the dollar amount.

Because the table is user-defined, the six values published by HL7 are starting points rather than a closed set. Hospitals routinely add codes for capitated arrangements, self-pay discounts, or workers'-comp pricing.

Where it's used

PV1-21 Charge Price Indicator — the canonical home of HL70032, populated on ADT^A01, ADT^A04, ADT^A08, and any other ADT event that carries a fully formed PV1.
Occasional vendor profiles reuse the table on financial-transaction segments (FT1) to tag individual line items with the same pricing posture; this is a non-standard extension.

Code list

Code	Display	Comment/Description
CH	Charges	Standard chargemaster rates apply — the default for self-pay and unlinked visits.
CO	Contract	A negotiated contract rate applies, typically a payer-specific fee schedule.
FP	Flat Price	A single bundled price for the visit (common for elective procedures, package pricing).
IC	Insurance Claim	Visit is being priced for submission on an insurance claim using the payer's allowed amounts.
PC	Price Constant	A constant price applies regardless of services rendered — used for fixed-fee programs.
RC	Reduced Charge	A discount has been pre-applied to the chargemaster (charity, employee, prompt-pay).

Code system OID

OID: 2.16.840.1.113883.18.12
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0032

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values for PV1-21.

HL7-defined vs user-defined

HL70032 is user-defined. The table number falls inside the HL7-reserved range, and HL7 publishes the six codes above as a starting set, but the table is explicitly extensible. Sites add codes — CAP for capitated, SP for self-pay-discount, WC for workers'-comp pricing — and conformant receivers are expected to tolerate unknown codes rather than reject the message. Vorro recommends registering every local extension in a site-specific value set so the OID metadata on outbound CWE-typed fields reflects the local code system, not the HL7 base.

Version differences

v2.1 – v2.3 — Table first appeared with the original four codes (CH, CO, FP, RC).
v2.3.1 — PC (Price Constant) added.
v2.4 — IC (Insurance Claim) added.
v2.5 – v2.8.1 — Set stable at six codes. HL7 has not added further values; growth happens via site extension.

Common mistakes

Treating HL70032 as a dollar amount. PV1-21 carries an indicator code, not a price; the actual rate lives in the financial transaction or claim segments.
Sending lowercase or mixed-case values (ch, Co). The codes are uppercase mnemonics; normalize on ingest.
Conflating IC (Insurance Claim) with the presence of an IN1 segment. A visit may have insurance coverage and still be priced under CH if the payer is being billed off the chargemaster.
Inventing local two-letter codes that collide with future HL7 additions. When extending the table, prefer three-character codes (CAP, WC, SPD) to leave headroom for HL7-defined growth.
Defaulting every visit to CH. Many EHRs populate PV1-21 with CH regardless of contract, which forces downstream billing to re-derive the arrangement and defeats the field's purpose.

Examples

A standard chargemaster visit:

PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A|||SUR||||ADM|A0|||004777^ATTEND^AARON^A|INP|1234567|CH

A visit priced under a payer contract:

PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A|||MED||||ADM|A0|||004777^ATTEND^AARON^A|INP|1234567|CO

A bundled flat-price elective procedure:

PV1|1|O|AMB^^01||||004777^SURG^SARAH^B|||SUR||||ELE|A0|||004777^SURG^SARAH^B|OUT|9988776|FP

A reduced-charge employee visit:

PV1|1|O|CLN^^01||||004777^GP^GREG^C|||GEN||||ROU|A0|||004777^GP^GREG^C|OUT|5544332|RC

Mapping failure example — unknown vendor code:

PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A|||SUR||||ADM|A0|||004777^ATTEND^AARON^A|INP|1234567|XYZ

XYZ is not in the published HL70032 set. Because the table is user-defined, a conformant engine should not reject the message; it should route the value to the terminology curation queue, preserve it in the audit log, and forward it untouched to downstream consumers that may understand the site extension.

FHIR mapping

HL70032 has no canonical FHIR ValueSet. The concept — billing arrangement on a specific encounter — does not have a single home in R4, and the v2-to-FHIR Implementation Guide does not publish a ConceptMap for it. Implementers usually surface the value in one of three ways:

HL70032 intent	FHIR target
Standard chargemaster	`Account.type` with a local code
Contract / payer arrangement	`Coverage.type` or `Coverage.class`
Visit-level pricing posture	Custom extension on `Encounter.account`

Whichever target is chosen, the original HL70032 code should be preserved as an extension so the v2 outbound channel can restore PV1-21 verbatim.

Engine considerations

Length — Codes are two characters in the HL7-published set. Engines should not hard-cap the field at two characters because site extensions are routinely three or four.
Case sensitivity — HL70032 codes are uppercase; normalize on ingest and reject mixed-case rather than silently uppercasing if conformance is strict.
CWE upgrade path — In v2.7+ profiles PV1-21 may be transmitted as CWE rather than IS. Engines must handle both shapes and populate CWE.14 with the OID when the destination demands it.
Default suppression — Avoid auto-populating PV1-21 with CH when the source system did not supply a value; an absent field is more honest than a misleading default.

How Vorro handles HL70032

Vorro validates PV1-21 against the six HL7-published codes plus any site-registered extensions on ingest. Values that match are forwarded untouched. Values that fail validation are routed to the terminology curation queue, where they either resolve to a known code (and a remap rule is created) or pass through with a soft warning so downstream billing systems are not silently fed unrecognized pricing indicators.

On outbound, Vorro emits HL70032 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations that advertise OID-bound coded values. When the value originates from a site extension, the CWE.12 (alternate code system) carries the site OID rather than the HL7 base.

Sources

← Back to HL7 v2 Guide