HL7 Table HL70114: Transfer to Bad Debt Code

HL70114 is a small user-defined v2 table whose values describe the reason a patient visit's outstanding balance has been moved from active receivables to bad debt. It is carried in PV1-38 Bad Debt Transfer Code, alongside PV1-37 Bad Debt Transfer Amount and PV1-39 Bad Debt Recovery Amount, and it tells downstream finance and reporting systems why the write-off happened so they can age, report, and pursue recovery appropriately.

Purpose

When a hospital writes a balance off to bad debt, the dollar amount is only part of the story. Auditors, payers, and charity-care reporting programs need to know whether the patient declared bankruptcy, died, was financially unable to pay, or simply refused — and they need that reason in a structured, codified form rather than as free text on the chart. HL70114 supplies the five-value enumeration that does that, drawn from the IS data type as single-digit codes.

Because the table is user-defined, the five values published by HL7 are starting points. Many hospitals add codes for charity-care, skip-tracing exhausted, statute-of-limitations expired, and other workflow-specific reasons.

Where it's used

PV1-38 Bad Debt Transfer Code — the canonical home of HL70114, populated on the ADT message that finalizes the write-off (typically an A08 visit update or an A01 retrospective correction).
Some vendor profiles repeat the value on a financial-transaction segment (FT1) when the write-off is captured as a discrete transaction rather than a visit attribute.

Code list

Code	Display	Comment/Description
1	Other	A reason that does not fit codes 2–5 — usually paired with a free-text comment elsewhere on the visit.
2	Bankruptcy	Patient has filed for bankruptcy; balance is non-collectible by court order.
3	Death of patient	Patient is deceased; balance moved to bad debt rather than to the estate.
4	Patient unable to pay	Financial-counseling determination that the patient cannot pay (often a precursor to charity-care reclassification).
5	Patient refusing to pay	Patient has been billed, contacted, and explicitly refuses to remit; collections exhausted.

Code system OID

OID: 2.16.840.1.113883.18.36
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0114

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-38.

HL7-defined vs user-defined

HL70114 is user-defined. The table number falls inside the HL7-reserved range, and HL7 publishes the five codes above as a starting set, but the table is explicitly extensible. Hospitals commonly add 6 for charity-care reclassification, 7 for statute-of-limitations expiration, 8 for skip-tracing exhausted, and similar workflow-specific reasons. Conformant receivers should tolerate unknown codes rather than reject the message, and outbound channels should populate CWE.14 with the appropriate code-system OID — HL7's base OID for codes 1–5, the site's local OID for extensions.

Version differences

v2.2 — Table first appeared with the five published codes; PV1-38 was added in the same version.
v2.3 – v2.8.1 — Set stable at five codes. HL7 has not added further values; growth happens via site extension.

Common mistakes

Confusing PV1-38 (bad debt transfer code) with PV1-37 (bad debt transfer amount). The code is a single digit; the amount is a money field.
Using 1 (Other) as a default for every write-off. The four specific reasons exist precisely so reporting can distinguish bankruptcy and death from refusals; defaulting to 1 defeats the purpose.
Sending the display word (Bankruptcy) instead of the code (2). PV1-38 is IS-typed and expects the digit.
Setting PV1-38 without also setting PV1-37. Many downstream finance systems treat a code without an amount as malformed and reject the message.
Overloading the field with date information. The transfer date belongs in a separate financial-transaction segment, not in PV1-38.

Examples

A visit written off because the patient declared bankruptcy:

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

Write-off following the death of the patient:

PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A|||MED||||ADM|A0|||004777^ATTEND^AARON^A|INP|1234567|CH|||||||||||||||||||3|2890.50|0.00

Financial-hardship write-off:

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

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|CH|||||||||||||||||||99|1450.00|0.00

99 is not in the published HL70114 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 so site-aware finance systems can interpret the local extension.

FHIR mapping

HL70114 has no canonical FHIR ValueSet. The concept — reason for transferring a balance to bad debt — 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:

HL70114 intent	FHIR target
Reason for write-off	`Account.status` extension carrying a CodeableConcept
Coverage-related write-off (bankruptcy, refusal)	`Coverage.exception` with a local reason code
Standalone financial event	`ChargeItem.reason` or a custom extension on `Invoice`

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

Engine considerations

Length — HL7-published codes are single digits. Engines should not hard-cap the field at one character because site extensions are routinely two or three.
Numeric vs string — PV1-38 is IS-typed, which means the value is a coded string even though the published codes happen to be numeric. Do not coerce to integer; leading zeros and non-numeric extensions are valid.
CWE upgrade path — In v2.7+ profiles PV1-38 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.
Companion fields — Always ship PV1-37 (amount) and PV1-39 (recovery) alongside PV1-38; absent companions trip many downstream finance validators.

How Vorro handles HL70114

Vorro validates PV1-38 against the five 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 finance systems are not silently fed unrecognized write-off reasons.

On outbound, Vorro emits HL70114 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, CWE.12 carries the site OID rather than the HL7 base.

Sources

← Back to HL7 v2 Guide