HL7 PV2 Patient Visit - Additional Information
HL7 field reference PV2 fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| PV2.1 | Prior Pending Location | No | No | PL | |
| PV2.2 | Accommodation Code | No | No | CE | 0129 |
| PV2.3 | Admit Reason | No | No | CE | |
| PV2.4 | Transfer Reason | No | No | CE | |
| PV2.5 | Patient Valuables | No | Yes | ST | |
| PV2.6 | Patient Valuables Location | No | No | ST | |
| PV2.7 | Visit User Code | No | Yes | IS | 0130 |
| PV2.8 | Expected Admit Date/Time | No | No | TS | |
| PV2.9 | Expected Discharge Date/Time | No | No | TS | |
| PV2.10 | Estimated Length of Inpatient Stay | No | No | NM | |
| PV2.11 | Actual Length of Inpatient Stay | No | No | NM | |
| PV2.12 | Visit Description | No | No | ST | |
| PV2.13 | Referral Source Code | No | Yes | XCN | |
| PV2.14 | Previous Service Date | No | No | DT | |
| PV2.15 | Employment Illness Related Indicator | No | No | ID | 0136 |
| PV2.16 | Purge Status Code | No | No | IS | 0213 |
| PV2.17 | Purge Status Date | No | No | DT | |
| PV2.18 | Special Program Code | No | No | IS | 0214 |
| PV2.19 | Retention Indicator | No | No | ID | 0136 |
| PV2.20 | Expected Number of Insurance Plans | No | No | NM | |
| PV2.21 | Visit Publicity Code | No | No | IS | 0215 |
| PV2.22 | Visit Protection Indicator | No | No | ID | 0136 |
| PV2.23 | Clinic Organization Name | No | Yes | XON | |
| PV2.24 | Patient Status Code | No | No | IS | 0216 |
| PV2.25 | Visit Priority Code | No | No | IS | 0217 |
| PV2.26 | Previous Treatment Date | No | No | DT | |
| PV2.27 | Expected Discharge Disposition | No | No | IS | 0112 |
| PV2.28 | Signature on File Date | No | No | DT | |
| PV2.29 | First Similar Illness Date | No | No | DT | |
| PV2.30 | Patient Charge Adjustment Code | No | No | CE | 0218 |
| PV2.31 | Recurring Service Code | No | No | IS | 0219 |
| PV2.32 | Billing Media Code | No | No | ID | 0136 |
| PV2.33 | Expected Surgery Date and Time | No | No | TS | |
| PV2.34 | Military Partnership Code | No | No | ID | 0136 |
| PV2.35 | Military Non-Availability Code | No | No | ID | 0136 |
| PV2.36 | Newborn Baby Indicator | No | No | ID | 0136 |
| PV2.37 | Baby Detained Indicator | No | No | ID | 0136 |
| PV2.38 | Mode of Arrival Code | No | No | CE | 0430 |
| PV2.39 | Recreational Drug Use Code | No | Yes | CE | 0431 |
| PV2.40 | Admission Level of Care Code | No | No | CE | 0432 |
| PV2.41 | Precaution Code | No | Yes | CE | 0433 |
| PV2.42 | Patient Condition Code | No | No | CE | 0434 |
| PV2.43 | Living Will Code | No | No | IS | 0315 |
| PV2.44 | Organ Donor Code | No | No | IS | 0316 |
| PV2.45 | Advance Directive Code | No | Yes | CE | 0435 |
| PV2.46 | Patient Status Effective Date | No | No | DT | |
| PV2.47 | Expected LOA Return Date/Time | No | No | TS | |
| PV2.48 | Expected Pre-admission Testing Date/Time | No | No | TS | |
| PV2.49 | Notify Clergy Code | No | Yes | IS | 0534 |
PV2 adds visit-level details that do not belong in the core PV1 segment.
Patient-administration segments add detail around the person, visit, account, diagnosis, procedure, insurance, merge, death, disability, and grouping state carried by the message.
These fields often drive matching, billing, encounter routing, reporting, and front-desk workflow. Separate patient identity, visit identity, account identity, and clinical facts carefully.
The v2.5.1 structures show PV2 in ADR_A19 - Patient query, ADT_A01 - Admit/visit notification, ADT_A02 - Transfer a patient, and ADT_A03 - Discharge/end visit, and 64 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
PV2-1 places the patient-administration workflow in an organization, facility, department, room, bed, or location group. Keep physical location, owning department, and receiving facility separate when the datatype allows it.
PV2-2 identifies the Accommodation Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0129; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-3 qualifies the patient-administration workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
PV2-4 qualifies the patient-administration workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
PV2-5 carries Patient Valuables for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PV2-6 places the patient-administration workflow in an organization, facility, department, room, bed, or location group. Keep physical location, owning department, and receiving facility separate when the datatype allows it.
PV2-7 identifies the Visit User Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PV2-8 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-9 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-10 carries Estimated Length of Inpatient Stay for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
PV2-11 carries Actual Length of Inpatient Stay for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
PV2-12 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
PV2-13 identifies the Referral Source Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PV2-14 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-15 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
PV2-16 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0213 or the narrower table in the local profile.
PV2-17 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-18 identifies the Special Program Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0214; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-19 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
PV2-20 is a count or total for this patient-administration workflow. Make the counting rule explicit before using it for reconciliation, billing, or workflow limits.
PV2-21 identifies the Visit Publicity Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0215; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-22 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
PV2-23 identifies an organization, clinic, facility, department, or company involved in this patient-administration workflow. Keep the organization identifier and display name separate when the datatype supports it.
Repeats should represent genuinely separate organizations or aliases, not several fragments of the same name.
PV2-24 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0216 or the narrower table in the local profile.
PV2-25 identifies the Visit Priority Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0217; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-26 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-27 qualifies the patient-administration workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0112. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PV2-28 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-29 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-30 identifies the Patient Charge Adjustment Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0218; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-31 identifies the Recurring Service Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0219; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-32 identifies the Billing Media Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0136; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-33 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-34 identifies the Military Partnership Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0136; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-35 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
PV2-36 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
PV2-37 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
PV2-38 identifies the Mode of Arrival Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0430; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-39 identifies the Recreational Drug Use Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PV2-40 identifies the Admission Level of Care Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0432; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-41 identifies the Precaution Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PV2-42 identifies the Patient Condition Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0434; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-43 identifies the Living Will Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0315; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-44 identifies the Organ Donor Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0316; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PV2-45 identifies the Advance Directive Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
PV2-46 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
PV2-47 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-48 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
PV2-49 identifies the Notify Clergy Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.