HL7 Table HL70042: Account Status

HL70042 is a user-defined HL7 v2 code table that records the financial lifecycle state of a patient account. It is carried in PV1-41 Account Status on ADT and DFT messages, and tells receiving systems whether an account is still accepting charges, has been closed out, has been written off as bad debt, or has been finalized for billing. Because the table is user-defined, every site is permitted to extend the published code set with local values — and most do — which makes HL70042 one of the more variable tables across real-world v2 traffic.

Purpose

HL70042 lets the registration/ADT system communicate the current accounting state of a visit account to downstream billing, scheduling, and clinical systems. A claim engine that sees F (Final Bill) on an inbound ADT knows not to append further charges; a clinical chart that sees C (Closed) knows the encounter is no longer in scope for new orders. Unlike clinical status fields, HL70042 is squarely a financial-cycle concept and should not be repurposed to convey visit clinical status (use PV1-44/PV1-45 or PV2 fields for that).

Where it's used

• PV1-41 Account Status — the canonical home of HL70042 on ADT, DFT, BAR, and SIU messages.
• Some site-specific Z-segments carrying derivative account-state fields reuse HL70042 by reference.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.15
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0042

The OID resolves on the HL7 Terminology server. In v2.7+ profiles where PV1-41 is transmitted as CWE, Vorro emits this OID in CWE.14 so downstream FHIR consumers can bind the code unambiguously.

HL7-defined vs user-defined

HL70042 is user-defined. The HL7 standard publishes the six suggested codes above as a starting set, but explicitly allows sites to add, redefine, or remove codes to match their accounting workflow. This is the single most important fact about HL70042: a code that means "Final Bill" at one hospital may be F, FB, FNB, or a vendor-specific 9 at the next. Integration engines must keep a per-source mapping table rather than assume the published values are universal.

Version differences

• v2.1 – v2.2 — Table introduced with the codes A, I, C as a minimal accounting cycle.
• v2.3 — B (Bad Debt) and F (Final Bill) added to support claims-cycle workflows.
• v2.4 – v2.6 — O (Open) added by some sites; HL7 included it in the suggested set.
• v2.7 – v2.8.1 — Set frozen at six suggested codes; PV1-41 data type widened to CWE in v2.7, allowing OID-bound transmission.

Common mistakes

• Treating HL70042 as HL7-defined and rejecting unknown codes outright. The table is user-defined; receivers should accept any value and log unknowns rather than NAK the message.
• Conflating account status with visit status. PV1-41 is the account state (financial); PV1-44/45 and PV2 carry visit timing/state.
• Defaulting F (Final Bill) to FHIR Account.status = active. A finalized account is no longer accepting charges and should map to inactive with a status reason.
• Sending the display word (Active) instead of the code (A). PV1-41 is IS or CWE; the code value is what travels.
• Silently dropping codes that do not match the six suggested values. The correct behavior is to preserve the raw code and route to terminology curation so a local mapping rule can be created.

Examples

A minimal PV1 with an active account:

PV1|1|I|3West^301^A^MAIN||||1234^SMITH^JOHN^A^^^MD|||SUR||||||||V|10456|||||||||||||||||||||||||A

PV1 for a finalized bill on discharge:

PV1|1|I|3West^301^A^MAIN||||1234^SMITH^JOHN^A^^^MD|||SUR||||||||V|10456|||||||||||||||||||||||||F

Same A value translated to a FHIR Account.status snippet:

{
  "resourceType": "Account",
  "id": "acct-10456",
  "status": "active",
  "subject": [{ "reference": "Patient/10456" }]
}

A B (Bad Debt) carries a richer FHIR shape because the FHIR status set does not include a bad-debt concept:

{
  "resourceType": "Account",
  "id": "acct-10456",
  "status": "inactive",
  "extension": [{
    "url": "http://example.org/fhir/StructureDefinition/account-status-reason",
    "valueCode": "bad-debt"
  }]
}

Mapping failure example — local site code:

PV1|1|I|3West^301^A^MAIN||||1234^SMITH^JOHN^A^^^MD|||SUR||||||||V|10456|||||||||||||||||||||||||X9

X9 is not in the suggested HL70042 set. Because the table is user-defined the receiver must not NAK, but instead preserve X9 in the audit log, attempt local-mapping resolution, and surface the value for terminology curation.

FHIR mapping

There is no published HL7 v2-to-FHIR ConceptMap for HL70042 (the v2-to-FHIR IG does not enumerate user-defined tables individually). The conventional mapping for PV1-41 onto FHIR Account.status (http://hl7.org/fhir/ValueSet/account-status) is:

Because FHIR Account.status is intentionally narrow (active / inactive / entered-in-error / on-hold / unknown), the additional accounting nuance from HL70042 must be carried as a status-reason extension if the receiver needs to round-trip back to v2.

Engine considerations

• User-defined table — never NAK on unknown — Receivers must accept any value in PV1-41; rejection breaks legitimate site customization.
• Per-source mapping — Maintain a mapping table keyed by sending facility (MSH-4) so that vendor variants of "Final Bill" all collapse to canonical F before downstream processing.
• CWE upgrade path — In v2.7+ profiles PV1-41 is CWE; populate CWE.14 with 2.16.840.1.113883.18.15 so downstream FHIR consumers can bind.
• Status-reason preservation — When mapping B or F to FHIR inactive, store the original HL70042 code as a status-reason extension so a v2 outbound channel can restore the distinction.

How Vorro handles HL70042

Vorro accepts any value in PV1-41 without NAK, normalizes case, and looks up the value in a per-source mapping table to produce a canonical HL70042 code. Unknown values are preserved verbatim, forwarded as-is on v2-to-v2 channels, and surfaced to the terminology curation queue so a site administrator can either bind the code to a canonical value or accept it as a new local extension.

On outbound, Vorro emits HL70042 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations. When mapping to FHIR Account.status, the original HL70042 code is stored as a status-reason extension so round-trip back to v2 preserves Bad Debt / Final Bill distinction.

Related pages

• PV1 segment — Patient Visit
• HL70001 code table — Administrative Sex
• IS data type — Coded Value for User-defined Tables

Sources

• Caristix — Table 0042 (HL7 v2.8.1) Account Status
• HL7 v2 product brief