HL7 Table HL70004: Patient Class

HL7 v2 table 0004 declares the kind of encounter a message describes — inpatient stay, outpatient visit, ED presentation, recurring infusion, preadmit registration. It is single-character coded and lives in PV1-2 Patient Class, which is the single most operationally important field in the PV1 segment for downstream routing. OID 2.16.840.1.113883.18.5, canonical URI http://terminology.hl7.org/CodeSystem/v2-0004.

Purpose

Patient Class lets every downstream system answer the question "should I care about this encounter?" without parsing diagnosis codes or bed locations. A bed-management system listens for I. A clinic schedule listens for O. A trauma registry listens for E. An infusion-center analytics pipeline listens for R. Pre-admission workflows (financial clearance, anaesthesia screening) listen for P.

Because it drives routing, table 0004 is one of the few HL7 vocabularies where a single-character typo (l instead of I) silently re-routes hundreds of messages per hour.

Where it's used

Field	Segment	Notes
PV1-2	PV1	Patient Class — required in most ADT profiles.

PV1-2 is required in nearly every PV1 profile. A blank PV1-2 typically triggers receiver-side validation failure.

Code list

Code	Display	Comment
B	Obstetrics
C	Commercial Account
E	Emergency
I	Inpatient
N	Not Applicable
O	Outpatient
P	Preadmit
R	Recurring Patient
U	Unknown

Code system OID and canonical URI

OID: 2.16.840.1.113883.18.5
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0004
FHIR ValueSet (mapped): http://terminology.hl7.org/ValueSet/v3-ActEncounterCode

HL7-defined vs user-defined

Table 0004 is HL7-defined but user-extensible — sites may add local codes (commonly H for Home Health, D for Dialysis, or numeric site codes) without violating conformance, provided the receiver has negotiated the extension. The base set above is reserved.

Version differences

v2.2: Original I/O/E/P set defined.
v2.3: B (Obstetrics) and R (Recurring) added.
v2.5: C (Commercial Account) added.
v2.6: N (Not Applicable) and U (Unknown) added — distinguishing "we know it doesn't apply" from "we don't know".
v2.8.1: No changes; set stable since v2.6.

Common mistakes

Sending blank PV1-2 for ED encounters. Many EHRs leave PV1-2 empty until admit decision; receivers should reject with AR and require E.
Using O for ED. ED is E, not O. Routing E as O floods outpatient clinics with trauma traffic.
Confusing P (Preadmit) with A05 event. PV1-2=P describes the class of encounter; A05 describes the event of pre-admission. Both should be present in an A05 message.
Custom values without negotiation. Sites add H (Home Health) freely. Downstream FHIR mappers may drop messages whose PV1-2 is outside the v3 ActEncounterCode binding.
Treating N and U as synonyms. They are not — N means the concept doesn't apply (e.g. a person-only message), U means the sender doesn't know.

Examples

Sample PV1 field

PV1|1|I|2W^201^A^HOSP||||1234^WELBY^MARCUS^^^^MD|||MED|||||...

FHIR Coding JSON

{
  "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
  "code": "IMP",
  "display": "inpatient encounter"
}

Note: the FHIR Encounter.class binding uses v3 ActEncounterCode, not v2-0004 directly. Direct v2 emission would use system: "http://terminology.hl7.org/CodeSystem/v2-0004", code: "I".

Mapping failure

An ambulatory surgery centre sends PV1-2 = A for "Ambulatory Surgery" (an unregistered local extension). The receiving HIE's v2-to-FHIR mapper has no entry for A, drops the Encounter.class, and the FHIR Encounter is rendered to clinicians with no visible class — making it indistinguishable from a phone call.

FHIR mapping

The v2-to-FHIR IG ConceptMap defines:

v2-0004	v3 ActEncounterCode	Display
I	IMP	inpatient encounter
O	AMB	ambulatory
E	EMER	emergency
P	PRENC	pre-admission
B	OBSENC	observation encounter
R	AMB	ambulatory (recurring loses fidelity)
C, N, U	(no map)	sender-specific or unknown

Engine considerations

Mirth: routing on msg['PV1']['PV1.2'].toString() is the common idiom; quotes around 'I' are easy to forget in JavaScript filter expressions.
Rhapsody: PV1-2 is exposed as a property on the patient-administration message object; filters use pv1.patientClass == 'I'.
HAPI: Terser.get(msg, "/PV1-2").
Receivers that downstream into FHIR should map before persisting — re-mapping from v2-0004 to v3 ActCode after the fact loses the R/AMB fidelity gap.

How Vorro handles

Vorro routes ADT traffic by composite key (MSH-9.2, PV1-2), so an A01|I (inpatient admit) is handled by a different policy than an A01|E (ED admit). The default policy library ships mappings for the nine canonical 0004 codes plus three common local extensions (H Home Health, D Dialysis, S Ambulatory Surgery), each negotiated per-customer. PV1-2 values outside the union of HL7-defined plus customer extensions raise a warning and route to a quarantine queue.

HL7 PV1 Segment — Patient Visit segment containing PV1-2.
HL7 Table 0007: Admission Type — companion vocabulary on PV1-4.
HL7 Table 0003: Event Type Code — ADT trigger events on MSH-9.

Sources

HL7 Terminology — CodeSystem v2-0004
HL7 v2-to-FHIR IG — ConceptMap table-hl70004 to v3 ActEncounterCode
HL7 v2.8.1 base standard, chapter 3 (Patient Administration)

← Back to HL7 v2 Guide