HL7 PV1 Patient Visit
HL7 field reference PV1 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 |
|---|---|---|---|---|---|
| PV1.1 | Set ID - PV1 | No | No | SI | |
| PV1.2 | Patient Class | Yes | No | IS | 0004 |
| PV1.3 | Assigned Patient Location | No | No | PL | 0079 |
| PV1.4 | Admission Type | No | No | IS | 0007 |
| PV1.5 | Preadmit Number | No | No | CX | |
| PV1.6 | Prior Patient Location | No | No | PL | 0079 |
| PV1.7 | Attending Doctor | No | Yes | XCN | 0010 |
| PV1.8 | Referring Doctor | No | Yes | XCN | 0010 |
| PV1.9 | Consulting Doctor | No | Yes | XCN | 0010 |
| PV1.10 | Hospital Service | No | No | IS | 0069 |
| PV1.11 | Temporary Location | No | No | PL | 0079 |
| PV1.12 | Preadmit Test Indicator | No | No | IS | 0087 |
| PV1.13 | Re-admission Indicator | No | No | IS | 0092 |
| PV1.14 | Admit Source | No | No | IS | 0023 |
| PV1.15 | Ambulatory Status | No | Yes | IS | 0009 |
| PV1.16 | VIP Indicator | No | No | IS | 0099 |
| PV1.17 | Admitting Doctor | No | Yes | XCN | 0010 |
| PV1.18 | Patient Type | No | No | IS | 0018 |
| PV1.19 | Visit Number | No | No | CX | |
| PV1.20 | Financial Class | No | Yes | FC | 0064 |
| PV1.21 | Charge Price Indicator | No | No | IS | 0032 |
| PV1.22 | Courtesy Code | No | No | IS | 0045 |
| PV1.23 | Credit Rating | No | No | IS | 0046 |
| PV1.24 | Contract Code | No | Yes | IS | 0044 |
| PV1.25 | Contract Effective Date | No | Yes | DT | |
| PV1.26 | Contract Amount | No | Yes | NM | |
| PV1.27 | Contract Period | No | Yes | NM | |
| PV1.28 | Interest Code | No | No | IS | 0073 |
| PV1.29 | Transfer to Bad Debt Code | No | No | IS | 0110 |
| PV1.30 | Transfer to Bad Debt Date | No | No | DT | |
| PV1.31 | Bad Debt Agency Code | No | No | IS | 0021 |
| PV1.32 | Bad Debt Transfer Amount | No | No | NM | |
| PV1.33 | Bad Debt Recovery Amount | No | No | NM | |
| PV1.34 | Delete Account Indicator | No | No | IS | 0111 |
| PV1.35 | Delete Account Date | No | No | DT | |
| PV1.36 | Discharge Disposition | No | No | IS | 0112 |
| PV1.37 | Discharged to Location | No | No | DLD | 0113 |
| PV1.38 | Diet Type | No | No | CE | 0114 |
| PV1.39 | Servicing Facility | No | No | IS | 0115 |
| PV1.40 | Bed Status | No | No | IS | 0116 |
| PV1.41 | Account Status | No | No | IS | 0117 |
| PV1.42 | Pending Location | No | No | PL | 0079 |
| PV1.43 | Prior Temporary Location | No | No | PL | 0079 |
| PV1.44 | Admit Date/Time | No | No | TS | |
| PV1.45 | Discharge Date/Time | No | Yes | TS | |
| PV1.46 | Current Patient Balance | No | No | NM | |
| PV1.47 | Total Charges | No | No | NM | |
| PV1.48 | Total Adjustments | No | No | NM | |
| PV1.49 | Total Payments | No | No | NM | |
| PV1.50 | Alternate Visit ID | No | No | CX | 0203 |
| PV1.51 | Visit Indicator | No | No | IS | 0326 |
| PV1.52 | Other Healthcare Provider | No | Yes | XCN | 0010 |
If PID tells us who the patient is, PV1 tells us the visit or account context the message is talking about. It is the segment that gives you the patient class, location, attending doctor, visit number, admit time, discharge time, and a fair amount of billing context. In ADT messages it is one of the big workhorse segments. In orders and results it often gives the receiving system enough encounter context to put the order or result in the right place.
The first mistake with PV1 is treating it as a second PID. It is not mainly about the person. It is about the patient's relationship to a particular hospital visit, outpatient encounter, preadmission, emergency visit, recurring treatment, or account. A patient can have many PV1 stories over time. If you use the patient identifier where you should have used the visit number, it may work in a test file and then become very interesting the day the same patient has two encounters open. A quick inspection in HL7 Soup Web helps here: compare PID-3 with PV1-19 and the patient identity/visit identity split becomes much less abstract.
The second mistake is forgetting that PV1 can be account-level or visit-level. The HL7 text says the default is account-level data, and PV1-51 is the field that can tell you it is visit-level data instead. Many systems ignore PV1-51 because their local feed has always meant one thing, but the distinction matters when you deal with patient accounts, multiple visits, or messages that carry PV1, PV2, ROL, DG1, OBX, and other segments under the same visit hierarchy. If Integration Soup is routing ADT updates by visit, make that account-versus-visit assumption explicit instead of leaving it hidden inside a map.
As usual, optional does not mean unimportant. In many real interfaces, the fields that make or break the message are PV1-2, PV1-3, PV1-7, PV1-10, PV1-19, PV1-36, PV1-44, PV1-45, and PV1-51. The rest of the segment has plenty of use, but a lot of it is only useful when the receiver is a patient administration, billing, bed management, or encounter management system that has agreed to use those fields deliberately.
So let's go through each of the PV1 fields and talk about how they tend to behave in real interfaces.
This is the sequence number for the PV1 segment. In most common ADT, ORM, and ORU messages you will see a single PV1 segment, and this is either empty or set to 1. When a message structure allows repeating visit groups, the set ID can help number those repetitions.
Do not use this as the visit identifier. It is not the visit number, account number, or episode number. If a receiver wants it valued, send 1 for the first PV1 and move on with your day. The useful encounter identifier is normally PV1-19.
PV1-2 is one of the most important fields in the segment. It tells the receiver the broad kind of patient encounter: inpatient, outpatient, emergency, preadmit, recurring, obstetrics, commercial account, unknown, and so on. A lot of downstream routing, reporting, billing, and display logic starts here.
Patient class is not the same thing as admission type, hospital service, patient type, or location. I for inpatient tells you the broad class of encounter. It does not tell you that the patient came through emergency, that the patient is under cardiology, or that the patient is in bed ICU-214-B. Those are different fields. When people use patient class as a general "where should I send this?" switch, it often works for the first three examples and then falls over on the fourth.
Be very careful with local mappings. Some systems send O for almost anything that is not admitted overnight. Others distinguish emergency from outpatient. Some use R for recurring oncology or dialysis encounters. Do not map every unfamiliar value to outpatient just to keep the interface moving. Unknown should be handled honestly, because a wrong class can change billing, reporting, and clinical workflow.
This is the current assigned patient location. It uses the PL data type, so the common pattern is point of care, room, bed, and facility: ICU^214^B^CITYHOSP. Later components can carry location status, location type, building, floor, a description, a comprehensive location identifier, and assigning authority. In practice, the first four components do most of the day-to-day work.
The facility component is easy to ignore until you have more than one facility. Then it becomes essential. The same ward, room, and bed code can exist at two hospitals, and the MSH sending facility is not always the same thing as the physical facility that owns the bed. If a site has more than one facility with bed locations, make sure PV1-3.4 is part of the location agreement.
Try not to flatten this into one free-text field unless the receiver truly cannot handle PL. Location codes are operational data. Bed boards, transfer messages, cleaning workflows, and patient tracking systems need to know which bit is the ward, which bit is the room, and which bit is the bed. A string like "ICU 214 Bed B" looks readable, but it asks every downstream system to become a tiny parsing project.
Admission type tells you the nature of the admission, such as emergency, urgent, elective, routine, accident, labor and delivery, or newborn. It is a different question from patient class. An inpatient admission can be emergency or elective. An emergency patient can later become inpatient. Those are not contradictions; they are different pieces of the encounter story.
This field often has local values, especially outside a strict national implementation guide. Use the values the receiver has agreed to, and do not infer them from the patient class unless that rule is documented. It is tempting to say PV1-2=E means PV1-4=E, but that is only safe if the sending system really uses those fields that way.
The preadmit number is an identifier used before the admission becomes a full visit or account. It is common in workflows where a planned admission is created ahead of time and then converted or linked when the patient actually arrives. Think of it as a preadmission handle, not necessarily the final visit number.
If your system receives both a preadmit number and a visit number, store both. The preadmit number can be useful when matching the original preadmission to the later admission event. Do not quietly replace PV1-19 with PV1-5 unless that is exactly how the local feed is designed.
PV1-6 carries the previous assigned patient location. It is especially useful in transfer messages, where PV1-3 tells you where the patient is now and PV1-6 tells you where they came from. A transfer from WARD^120^A to ICU^214^B is much easier to reason about when both sides of the movement are present.
This is not a complete location history. It is the prior location relevant to the current event. If a receiver needs a full movement timeline, it should build that from the stream of ADT events or use a profile designed to carry that history. PV1-6 is a useful breadcrumb, not the whole trail.
PV1-7 is the attending doctor for the visit. The data type is XCN, so the most useful value includes a provider identifier, family name, given name, and assigning authority or identifier type. For example, 277^Allen^Katrina^J^^Dr^^^NPI^L^^^^NPI is much easier to match than just Allen.
In many interfaces, this is the provider who has overall responsibility for the patient's care during the encounter. That does not make it the ordering provider, result interpreter, consulting provider, or admitting provider. HL7 has separate places for those ideas. If the feed has multiple provider roles, look carefully at PV1-7, PV1-8, PV1-9, PV1-17, PV1-52, ORC fields, OBR fields, and sometimes ROL segments before deciding which human goes where.
The field repeats, but repeating the attending doctor is not a magic fix for poor role modeling. If you have several care team members with different roles, a role-based segment such as ROL may be cleaner in profiles that use it. At the very least, make sure the receiver knows what each repeat means.
PV1-8 is the referring doctor. This is usually the provider who referred the patient into the service or encounter. In outpatient, diagnostic, specialist, and referral workflows it can be one of the most important provider fields, because correspondence and results may need to go back to this person.
Again, identifiers beat names. A provider name can change, be misspelled, or collide with another provider. A stable provider number with an assigning authority is much safer. If you are integrating with systems that use national identifiers such as NPI in the US, or local provider registers elsewhere, put that identifier in the structured XCN components rather than hiding it in text.
PV1-9 carries a consulting doctor. Depending on the system, this may be a specialist consulted during the encounter, a doctor providing advice, or a local role that is not quite attending or referring. The exact meaning is often more local than people expect.
If your workflow has several consultants, check the implementation guide carefully. Some modern profiles prefer role-bearing segments for this sort of care team information, because a single "consulting doctor" field does not explain much about specialty, start time, end time, or responsibility. If you do use PV1-9, send XCN properly and agree what the repeat order means.
Hospital service describes the service or department responsible for the encounter, such as medicine, surgery, cardiology, pulmonary, or urology. It is not the same thing as the patient's physical location. A cardiology patient can be in an ICU bed. A surgical patient can be temporarily in imaging. Keep the service and the location separate.
This field is often used for routing and filtering. A results interface might send some results to a specialist system based on hospital service. A bed board might group encounters by service. Use agreed codes rather than display names where possible. MED and Medical Service are easy for people to read, but a receiver should not have to do fuzzy matching on department names.
Temporary location is for a place the patient is temporarily located, while the assigned location remains something else. This might be a procedure area, imaging department, recovery area, or another transient location depending on the local system.
The important thing is to agree whether the receiver should treat PV1-11 as current physical location or only as a temporary note. If a patient is assigned to ICU-214 but is currently in CT, some systems want CT in PV1-11 while PV1-3 remains ICU-214. Other systems send a full transfer instead. Both can be valid, but mixing them casually causes bed and tracking displays to disagree.
This field flags preadmission testing. It is an older patient administration field, and many interfaces leave it empty. When it is used, it is normally about whether preadmission tests are required, ordered, or completed according to the local patient administration workflow.
I would not use this as a replacement for actual orders or results. If you need to send the details of preadmission tests, use the order and observation structures that carry those details properly. PV1-12 is a high-level administrative flag.
The readmission indicator marks that the encounter is a readmission according to the local rules. That phrase "according to the local rules" is doing a lot of work. One site may mean a readmission within 30 days. Another may mean related to the same condition. Another may only use the field for a specific reporting workflow.
Do not calculate this from dates in the receiving interface unless that is the agreed design. If the sender is the patient administration system, it is usually the system with the business rule. If you need the value for reporting, make sure the definition is written down, because readmission statistics are the sort of thing people take quite seriously.
Admit source tells you where the patient came from or how they arrived into the encounter: emergency room, physician referral, transfer from another facility, court/law enforcement, newborn, or other local source categories. The base table is often locally extended or replaced by an implementation guide.
Admit source is not admission type. "Emergency" as a source and "Emergency" as a type may look similar, but one is about where the patient came from and the other is about the urgency or nature of the admission. If both fields are populated, keep both meanings intact. They answer different operational questions.
Ambulatory status carries functional or special-care flags such as no functional limitations, wheelchair or stretcher bound, oxygen therapy, hearing impaired, vision impaired, speech impaired, non-English speaking, pregnant, and similar values. It repeats because more than one status can apply.
This field can be helpful for transport, appointment preparation, and patient movement workflows, but it can also be stale, sensitive, or too blunt for modern care planning. If you use it, use it for the workflow it was agreed for. Do not treat it as a complete disability model, interpreter request, mobility assessment, or clinical observation. Better sources may exist elsewhere in the message set.
The VIP indicator is for special handling of a patient or account. In real life this might be used for high-profile patients, staff members, privacy-sensitive encounters, or other local categories where access or display needs extra care.
This is not a field to spray through every interface because it looks harmless. If it has privacy meaning, only send it where the receiver has a legitimate use and knows what to do with it. Also be clear whether the flag should affect access control, auditing, display labels, or only clerical handling. "VIP" is a small field name for a potentially large policy decision.
PV1-17 is the admitting doctor: the provider associated with admitting the patient. In some workflows this may be the same as the attending doctor, and in others it is not. The admitting doctor may be the doctor who accepted the admission, while the attending doctor is the provider responsible for ongoing care.
Use the same XCN discipline here as for PV1-7 and PV1-8. Provider identifiers should be stable, names should be componentized, and the assigning authority should be clear. If the source sends the same provider in attending and admitting, that is fine when true. Do not copy it across just to avoid an empty field.
Patient type is a site-specific patient administration category. It is commonly used for local billing, operational, or reporting groupings. Unfortunately, the name is vague enough that people are tempted to put almost anything in it.
Keep it separate from patient class. PV1-2 might say inpatient, while PV1-18 might say acute, rehab, private, compensable, or another local category. If your receiver does not have a defined use for patient type, leaving it empty is usually better than inventing a value from nearby fields.
PV1-19 is the big encounter identifier. In many systems it is the visit number, encounter number, case number, episode number, or the closest local equivalent. If you are trying to attach an order, result, document, charge, or note to the right visit, this is often the field you are hunting for.
Use the CX data type properly. A visit number like V123456^^^CITYHOSP^VN tells the receiver the value, the assigning authority, and the identifier type. That is much better than V123456 floating by itself. The same numeric value can exist in different facilities, different systems, or different identifier namespaces.
PV1-19 is not the patient identifier and it is not the patient account number in PID-18. A patient identifier tells you who the person is. A visit number tells you which encounter you are talking about. An account number may be a billing construct that covers one or more visits depending on the organisation. Keeping those separate saves a lot of pain.
Financial class is a billing or payer category, often used for values such as private, Medicare, Medicaid, self-pay, workers compensation, or local contract categories. The data type can include an effective date, which matters if the financial class changes during an account.
This is not the same as the detailed insurance information. Insurance lives more naturally in IN1 and related insurance segments. PV1-20 is a higher-level class used for patient administration and billing behavior. If the receiver is not a financial or registration system, it may not need this field at all.
PV1-21 is the charge price indicator, PV1-22 is the courtesy code, and PV1-23 is the credit rating. These are old-school patient accounting fields. They can matter in billing feeds, account maintenance messages, or integrations with systems that still use these categories.
For most clinical interfaces, these fields are empty and that is fine. Do not send financial handling flags to a clinical receiver unless there is a defined need. They can be misunderstood, and they usually do not help a lab, imaging viewer, or clinical results interface do its job.
These four fields carry contract code, contract effective date, contract amount, and contract period. They repeat together, so if you use more than one contract repeat, make sure the nth contract code lines up with the nth date, amount, and period. This is one of those areas where repetition can become messy very quickly if both systems are not strict.
Use these fields only when the interface is genuinely carrying contract or billing arrangement information. They are not a good place for general payer notes or free-text funding explanations. If you need full insurance or guarantor detail, look at the insurance and guarantor segments instead.
PV1-28 through PV1-35 are financial account lifecycle fields: interest code, transfer to bad debt code and date, bad debt agency, bad debt amounts, delete account indicator, and delete account date. They are useful in patient accounting systems and billing-specific feeds, but they are usually noise in clinical messaging.
Be careful with these fields because they sound administrative but can have real consequences in the receiving system. A delete account indicator should not be casually mapped from a cancellation event. Bad debt values should not be sent to systems that do not need them. If your integration is not part of the account lifecycle, these fields are best left alone.
Discharge disposition tells you the outcome or disposition when the patient leaves the encounter. It may say the patient went home, transferred to another facility, left against medical advice, expired, went to rehabilitation, and so on depending on the local or national code set.
This is not the discharge date and time. That is PV1-45. It is also not always the literal destination address. PV1-36 is the category of disposition. PV1-37 can carry the discharged-to location. In discharge messages, PV1-36 is often one of the most important fields for reporting and downstream workflow, so do not reduce it to a note unless the receiver really cannot handle coded values.
PV1-37 carries the location the patient was discharged to. This may be a facility, ward, home, nursing facility, rehabilitation centre, or another local destination value. It complements PV1-36 rather than replacing it.
For example, PV1-36 might say transfer to another healthcare facility, while PV1-37 gives the actual facility. If the receiver only needs the disposition category, PV1-36 may be enough. If transport, referral, or follow-up workflows need the destination, PV1-37 becomes useful.
Diet type is a patient administration field for dietary category. In many modern workflows, detailed diet orders are handled by order messages rather than PV1. Still, some admission and bed-management systems use PV1-38 as a simple dietary flag.
If you use it, keep it coded and local-guide driven. Do not try to squeeze a full diet order, allergy list, swallow assessment, or nutrition note into this field. It is a simple administrative diet category, not the full dietary story.
Servicing facility identifies the facility providing the service for this account or visit. This can differ from the sending facility in MSH and from the facility component of a particular patient location. In multi-site organisations, that difference matters.
Use this field when the receiver needs to know which facility is responsible for the encounter or service. If you also send PV1-3.4, make sure the relationship is understood. A patient may be physically located in one facility, administratively serviced by another, and messaged through a central integration engine.
Bed status is an older field for values such as occupied, unoccupied, housekeeping, isolated, contaminated, or closed. The HL7 refactored text treats this field as backward compatibility, so do not assume it is the modern source of truth for bed state.
In many interfaces, bed status is better derived from bed-management events and patient location. If a legacy receiver requires PV1-40, populate it with the agreed local table. Otherwise, be cautious. A stale bed status is worse than an empty one because it looks operationally meaningful.
Account status is about the patient account, not the clinical status of the patient. It may be used by billing or registration systems to show whether an account is active, inactive, closed, discharged, or in another local status.
Do not confuse this with patient class, discharge disposition, or appointment status. If you need to know whether the encounter has ended, PV1-45 and the relevant ADT event are normally more informative. PV1-41 belongs to the account lifecycle.
Pending location is the location the patient is expected to move to. This is useful in bed management and transfer workflows where the new location is planned or assigned but the transfer has not happened yet.
Keep it separate from PV1-3. PV1-3 is the assigned current location. PV1-42 is the pending one. If the receiver treats pending location as current location too early, patients can appear in two beds or disappear from the one they are actually in.
Prior temporary location is the previous value for the temporary location. It is a fairly narrow field, mostly useful when a system tracks temporary locations separately from assigned patient locations.
If your feed does not use PV1-11 consistently, PV1-43 will not be very useful either. Like the other location fields, it should use PL structure rather than free text when it is populated.
PV1-44 is the admit date and time for the encounter. In ADT messages it is one of the core timestamps. It is not the message timestamp in MSH-7, and it is not necessarily the exact time the interface sent the event. It is the time the patient was admitted, registered, or started the encounter according to the patient administration system.
Use the HL7 timestamp format and agree timezone behavior. Many older systems send local time without an offset. That can be fine inside one hospital, but it becomes risky when messages cross regions, hosted systems, or daylight saving transitions. If your database stores UTC, convert deliberately and keep enough context to explain what happened.
PV1-45 is the discharge date and time. It should normally appear when the encounter is discharged or ended. For a patient who is still admitted, it is usually empty. For historical data loads, it may be populated even though the message event is not a discharge event.
Do not treat a blank discharge date as absolute proof that the patient is currently admitted unless the feed is designed that way. Some systems omit historical discharge times from certain message types. Others only send them on A03-style discharge messages. As always, the event, the field, and the interface guide need to agree.
These four fields carry financial totals: current patient balance, total charges, total adjustments, and total payments. They are account values, not clinical values. In a billing interface they may be exactly what you need. In a clinical interface they are usually unnecessary.
If you use them, agree decimal precision, currency assumptions, and whether the totals are lifetime account totals, current encounter totals, or point-in-time values. A number without that context can be dangerously tidy.
PV1-50 carries another visit identifier. It can be useful when one system has an encounter number and another has a case number, external visit ID, or legacy visit identifier. Like PV1-19, it uses CX, so assigning authority and identifier type are important.
Do not use alternate visit ID as a dumping ground for every other number you could not place. If the alternate ID has business meaning, document it. If the receiver should match on it, say whether it is secondary, historical, cross-facility, or only used by a particular downstream system.
PV1-51 is small but important. It tells you whether the PV1 hierarchy is account-level or visit-level. The local HL7 table has A for account level and V for visit level. The standard text says account level is the default, and visit-level data should be marked with V.
If your interface has one account per visit, this may feel academic. It stops feeling academic as soon as you have one account with multiple visits, recurring treatment, account updates, or diagnosis and observation segments attached under a PV1 hierarchy. If the sender uses PV1-51, pay attention to it. If the sender leaves it empty but the feed clearly behaves as visit-level, write that assumption into the interface specification rather than leaving it as shared folklore.
PV1-52 is another provider field. In later HL7 thinking it is treated as backward compatibility, because role-based provider representation is usually better handled elsewhere. Still, v2.5.1 feeds may use it, and older systems may expect it.
If you use PV1-52, agree what "other" means. Other attending? Other care provider? Primary care provider? Responsible nurse? Without a role, the receiver can only guess. In profiles that support ROL or other role-bearing structures, those are usually a cleaner way to describe extra healthcare providers.