Testing HL7 v2 PV1-18: What Patient Type Actually Needs to Handle
PV1-18 uses code values that often look nearly identical to PV1-2, which leads a lot of integrations to treat them as duplicates of each other — right up until a facility configures the two fields to diverge, and half the billing logic built on that assumption quietly breaks.
PV1-18 is the eighteenth field of the PV1 segment — a site-defined code classifying the patient type for billing and reporting purposes, maintained separately from Patient Class in PV1-2.
Common code values (facility-defined, examples only)
Example
The 18th field (I) marks the patient type as inpatient, matching Patient Class here — but the two fields are independently maintained. Synthetic patient — not a real person.
Where this trips people up
Some facilities use PV1-18 specifically to flag billing-relevant statuses — like observation stays that are clinically similar to inpatient care but reimbursed differently — while PV1-2 stays "I" the whole time. Interfaces that read only Patient Class and ignore Patient Type will miss that distinction entirely, which is a real problem when observation-versus-inpatient status directly affects how a claim gets paid.