Testing HL7 v2 PV2: The Fields Your System Actually Needs to Handle
PV2 shows up in almost every ADT feed your integration team touches, and almost nobody can rattle off what half its fields mean. That gap is exactly where go-live defects hide.
PV2 (Patient Visit - Additional Information) is the segment that carries the supplementary visit details PV1 has no room for - things like the accommodation requested, why the patient was admitted, expected admit and discharge windows, accident details for claims, and the patient status code a downstream system uses to drive bed and billing workflows. It rides along with PV1 in ADT and related messages and is almost always optional, which is exactly why real-world implementations disagree so often about which fields they actually populate.
The fields that actually matter in practice
Example
Synthetic PV2 segment for a fictional appendicitis admission - accommodation, admit reason, expected admit/discharge window, an accident timestamp, and a patient status code, with unused fields left empty.
Where this trips people up
Because nearly every PV2 field is optional, production feeds from different source systems populate wildly different subsets of it. A test suite built against one vendor's PV2 habits will happily pass in staging and then choke the moment a second source system sends a message with, say, Patient Status populated in a code system nobody mapped. The fix isn't exhaustive field coverage - it's deliberately generating PV2 variants that mirror the actual diversity of your upstream sources, including the ones that leave a field blank when you expected a value.