HL7 PR1 Procedures
HL7 field reference PR1 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 |
|---|---|---|---|---|---|
| PR1.1 | Set ID - PR1 | Yes | No | SI | |
| PR1.2 | Procedure Coding Method | No | No | IS | 0089 |
| PR1.3 | Procedure Code | Yes | No | CE | 0088 |
| PR1.4 | Procedure Description | No | No | ST | |
| PR1.5 | Procedure Date/Time | Yes | No | TS | |
| PR1.6 | Procedure Functional Type | No | No | IS | 0230 |
| PR1.7 | Procedure Minutes | No | No | NM | |
| PR1.8 | Anesthesiologist | No | Yes | XCN | 0010 |
| PR1.9 | Anesthesia Code | No | No | IS | 0019 |
| PR1.10 | Anesthesia Minutes | No | No | NM | |
| PR1.11 | Surgeon | No | Yes | XCN | 0010 |
| PR1.12 | Procedure Practitioner | No | Yes | XCN | 0010 |
| PR1.13 | Consent Code | No | No | CE | 0059 |
| PR1.14 | Procedure Priority | No | No | ID | 0418 |
| PR1.15 | Associated Diagnosis Code | No | No | CE | 0051 |
| PR1.16 | Procedure Code Modifier | No | Yes | CE | 0340 |
| PR1.17 | Procedure DRG Type | No | No | IS | 0416 |
| PR1.18 | Tissue Type Code | No | Yes | CE | 0417 |
| PR1.19 | Procedure Identifier | No | No | EI | |
| PR1.20 | Procedure Action Code | No | No | ID | 0206 |
PR1 records procedures associated with a patient, visit, account, or billing workflow.
The standard describes PR1 this way: The PR1 segment contains information relative to various types of procedures that can be performed on a patient. The PR1 segment can be used to send procedure information, for example: Surgical, Nuclear Medicine, X ray with contrast, etc. The PR1 segment is used to send multiple procedures, for example, for medical records encoding or for billing systems.
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 PR1 in ADR_A19 - Patient query, ADT_A01 - Admit/visit notification, ADT_A03 - Discharge/end visit, and ADT_A05 - Pre-admit a patient, and 12 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.
PR1-1 is the sequence number for this PR1 segment within its repeating group. It keeps multiple PR1 lines in order; it is not the business identifier for the patient-administration workflow.
PR1-2 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 0089. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PR1-3 identifies the Procedure 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 0088; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PR1-4 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.
PR1-5 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.
PR1-6 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 0230. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PR1-7 is clinical or administrative context for the patient-administration workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
PR1-8 carries Anesthesiologist 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.
The generated panel links this to HL7 table 0010; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PR1-9 identifies the Anesthesia 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 0019; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PR1-10 carries Anesthesia Minutes 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.
PR1-11 carries Surgeon 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.
The generated panel links this to HL7 table 0010; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PR1-12 identifies a person, provider, staff member, or contact involved in this patient-administration workflow. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
PR1-13 identifies the Consent 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 0059; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PR1-14 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 0418. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PR1-15 identifies the Associated Diagnosis 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 0051; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PR1-16 is clinical or administrative context for the patient-administration workflow. Use the coded value, lifecycle status, and timing fields together so a receiver can decide whether it is new, changed, resolved, cancelled, or historical.
The generated panel links this to HL7 table 0340; many real interfaces narrow that list further, so follow the receiver's implementation guide.
PR1-17 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 0416. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PR1-18 identifies the Tissue Type 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.
PR1-19 identifies the Procedure Identifier 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.
PR1-20 says what action is being taken for this segment or record: add, update, delete, cancel, clear, or another profile-defined operation. It needs to agree with the message trigger and the previous state.
The generated panel links this to HL7 table 0206; many real interfaces narrow that list further, so follow the receiver's implementation guide.
Related links
- PID - Patient Identification
- PD1 - Patient Additional Demographic
- PV1 - Patient Visit
- PV2 - Patient Visit - Additional Information
- DG1 - Diagnosis
- DRG - Diagnosis Related Group
- IN1 - Insurance
- IN2 - Insurance Additional Information
- IN3 - Insurance Additional Information, Certification
- MRG - Merge Patient Information