Reference·HL7 v2·PR1
HL7 v2 Reference

HL7 v2 PR1 Segment Guide: Fields, Format, and Testing Gotchas

Jul 27, 2026 · 6 min read

PR1 carries the procedure that actually happened, not what was scheduled or ordered. Confuse those two and a billing feed can walk out the door claiming a patient had a laparoscopic procedure when the surgeon converted to open partway through the case.

Quick answer

PR1 (Procedures) is the repeating HL7 v2 segment that records a procedure performed on a patient, including its code, description, timing, and type. It typically shows up in ADT and DFT messages tied to inpatient or surgical encounters, with one PR1 segment per procedure performed during the visit.

The fields that actually matter in practice

PR1-1 →
Set ID — numbers each PR1 when a visit has multiple procedures — get this wrong and a secondary procedure can silently overwrite the primary one downstream
PR1-3 →
Procedure Code — the coded identifier for what was actually done, usually CPT or ICD-PCS — the field billing and reporting systems key off of
PR1-4 →
Procedure Description — a free-text or coded label describing the procedure, meant to travel alongside the code, not replace it
PR1-5 →
Procedure Date/Time — when the procedure was actually performed, distinct from when it was scheduled or ordered
PR1-6 →
Procedure Type — classifies whether the procedure was primary, secondary, or something else — determines how downstream systems rank multiple PR1 segments
PR1-10 →
Surgeon — identifies who performed the procedure, separate from the ordering or attending provider carried elsewhere in the message

Example

Synthetic example Generated by Synthibase
PR1|1||47562^LAPAROSCOPIC CHOLECYSTECTOMY^CPT|LAPAROSCOPIC REMOVAL OF GALLBLADDER VIA FOUR SMALL ABDOMINAL INCISIONS|20260726103000|P||8842^REYES^MONICA^L^^^MD

A synthetic PR1 segment for a laparoscopic gallbladder removal, showing the CPT-coded procedure, its performed date/time, a primary-procedure type flag, and the operating surgeon.

Where this trips people up

Teams frequently test PR1 using only the scheduled or planned procedure, then assume the field mapping is solid. In production, PR1-3 and PR1-4 have to reflect what actually happened, which can diverge from the pre-op plan — a laparoscopic case that converts to open, or a diagnostic procedure that becomes therapeutic mid-encounter. If the interface engine populates PR1 from an order-entry system snapshot instead of the post-procedure documentation, downstream billing systems end up coding for a procedure that never occurred. Test suites should include at least one case where the performed procedure differs from what was originally ordered, and verify PR1-6's type code correctly distinguishes primary from secondary procedures when a visit has more than one PR1 segment.

How to Reduce Claim Denials Through Better Pre-Submission Testing
HL7 ADT Messages: A01 through A08 Explained
Test PR1 handling without waiting on a live OR feed
Synthibase generates realistic, synthetic HL7 v2 procedure messages on demand so your team can validate PR1 field mapping, procedure-type ranking, and surgeon attribution before anything touches production data.
Start free trial →
This page is written independently by Synthibase for testing and informational purposes. It is not an official publication of HL7 International or X12/Washington Publishing Company, and is not a substitute for reviewing the official standard or your trading partner's companion guide. See our Terms of Service for full legal terms.