The PRD (Provider Data) segment carries information about the providers involved in a patient referral. It identifies each provider's role in the referral, their name, address, location, contact methods, identifiers, and the dates the role was effective. PRD is highly repeatable at the field level, allowing a single provider entry to hold multiple roles, names, addresses, and contact numbers.
Unlike the personnel detail segments AFF, EDU, and LAN that ride inside a staff master file, PRD lives inside referral messages and describes the parties to a specific referral. It shares consistent personnel and credential terminology with those segments and is frequently paired with CTD (Contact Data) for detailed contact roles.
Purpose
The purpose of PRD is to describe who is involved in a referral and in what capacity — for example the referring provider, the referred-to provider, and the primary care provider. Each PRD occurrence binds a provider role to the provider's identity and contact information so the receiving system can route, acknowledge, and act on the referral. The effective start and end dates let the role be time-bounded within the referral context.
PRD is the anchor provider segment of a referral. It typically repeats once per party in the referral and is often followed by one or more CTD segments that elaborate on contact persons for that provider.
Used in
PRD is used in the REF message family — specifically the REF^I12 patient referral message. Within that message PRD follows the PID (Patient Identification) segment and describes each provider participating in the referral. The REF message communicates a patient referral from one provider or organization to another, and PRD carries the provider-identity portion of that exchange.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (https://hapifhir.github.io/hapi-hl7v2/v251/apidocs/ca/uhn/hl7v2/model/v251/segment/PRD.html) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| PRD-1 | Provider Role | ce | — | R | Y | HL70286 | Role this provider plays in the referral |
| PRD-2 | Provider Name | xpn | — | O | Y | — | Name of the provider |
| PRD-3 | Provider Address | xad | — | O | Y | — | Mailing or practice address of provider |
| PRD-4 | Provider Location | pl | — | O | — | — | Physical location of the provider |
| PRD-5 | Provider Communication Information | xtn | — | O | Y | — | Phone, fax, or email contact details |
| PRD-6 | Preferred Method of Contact | ce | — | O | — | — | Preferred way to reach the provider |
| PRD-7 | Provider Identifiers | pln | — | O | Y | — | Practitioner license or provider numbers |
| PRD-8 | Effective Start Date of Provider Role | ts | — | O | — | — | When the provider role became effective |
| PRD-9 | Effective End Date of Provider Role | ts | — | O | — | — | When the provider role ended |
Most-used fields
PRD-1 (Provider Role) is the only required field and is bound to HL70286; it distinguishes the referring provider from the referred-to provider and is what receivers key on to route the referral. PRD-2 (Provider Name) is almost always present and repeats to allow alternate name representations. PRD-3 (Provider Address) and PRD-5 (Provider Communication Information) carry the contact data needed to reach the provider, both repeating for multiple addresses or numbers. PRD-7 (Provider Identifiers) is heavily used for license and NPI-style numbers that uniquely identify the provider across systems.
Version differences (2.3 to 2.8.2)
PRD has carried its nine-field structure since HL7 v2.3 and retains it through v2.8.2. The repetition characteristics — PRD-1, PRD-2, PRD-3, PRD-5, and PRD-7 repeating — are stable across the range. The principal evolution is in data types: PRD-8 and PRD-9 are TS (time stamp) in v2.5.1 and were realigned toward DTM in v2.7 and later as HL7 migrated time-stamp fields, and the XPN, XAD, and XTN types used by PRD-2, PRD-3, and PRD-5 gained additional components in later versions. No PRD field was added, removed, or renumbered, but transforms that move between v2.5.1 and v2.7+ must account for the TS-to-DTM change in the effective-date fields.
Common mistakes
The most common mistake is omitting PRD-1 (Provider Role) or sending an uncoded value, which leaves the receiver unable to tell the referring provider from the referred-to provider. Another is sending one PRD per role on the same person rather than repeating PRD-1 within a single PRD when a provider genuinely holds multiple roles. Implementers also confuse PRD-3 (a structured XAD address) with PRD-4 (a PL physical location), placing a building/room location in the address field. Finally, contact numbers belong in PRD-5 (XTN), not concatenated into the name or address, and identifiers belong in PRD-7 (PLN) rather than a free-text field.
Examples
Minimal PRD (role and name only):
PRD|RP^Referring Provider^HL70286|Okafor^Adaeze^N^^Dr^MD
Fully-populated PRD:
PRD|RP^Referring Provider^HL70286|Okafor^Adaeze^N^^Dr^MD|44 Lakeshore Dr^Suite 210^Evanston^IL^60201^USA|^^^NORTHCLINIC^^^^^North Clinic Cardiology|^WPN^PH^^1^312^5550148~^NET^Internet^aokafor@northclinic.example|PH^Phone^HL70185|9988776^NPI^^^MR|20260601120000|20260910120000
Annotated breakdown:
PRD|RP^Referring Provider^HL70286|Okafor^Adaeze^N^^Dr^MD|44 Lakeshore Dr^...|^^^NORTHCLINIC^...|^WPN^PH^...|PH^Phone^HL70185|9988776^NPI^...|20260601120000|20260910120000
| | | | | | | |
| | | | | | | +--> PRD-9 Effective End Date of Role (TS)
| | | | | | +-------------------> PRD-8 Effective Start Date of Role (TS)
| | | | | +--------------------------------------> PRD-7 Provider Identifiers (PLN)
| | | | +-----------------------------------------------------------> PRD-6 Preferred Method of Contact (CE)
| | | +----------------------------------------------------------------------------> PRD-5 Provider Communication Information (XTN, repeats)
| | +------------------------------------------------------------------------------------------------> PRD-4 Provider Location (PL)
| +------------------------------------------------------------------------------------------------------------------------> PRD-3 Provider Address (XAD, repeats)
| (PRD-2 Provider Name, XPN, repeats) ----------------------------------------------------------------------------------------^
+------------------------------------------------------------------------------------------------------------------------------------------------------> PRD-1 Provider Role (CE, repeats) = Referring Provider
In-context excerpt 1 — PRD inside a REF^I12 patient referral message, following PID, with referring and referred-to providers:
MSH|^~&|EHR|NORTHCLINIC|EHR|CARDIOGROUP|20260610120000||REF^I12^REF_I12|MSG00071|P|2.5.1
RF1|P^Pending^HL70283|R^Routine^HL70280|MED^Medical^HL70281|||REF20260610001|||20260610120000
PID|1||MRN778812^^^NORTHCLINIC^MR||Alvarez^Marisol^T||19771103|F|||128 Birch Ln^^Evanston^IL^60202^USA
PRD|RP^Referring Provider^HL70286|Okafor^Adaeze^N^^Dr^MD|44 Lakeshore Dr^Suite 210^Evanston^IL^60201^USA|||^WPN^PH^^1^312^5550148|PH^Phone^HL70185|9988776^NPI^^^MR
PRD|RT^Referred to Provider^HL70286|Ramirez^Carlos^^^Dr^MD|901 Michigan Ave^Suite 50^Chicago^IL^60611^USA|||^WPN^PH^^1^312^5550199|PH^Phone^HL70185|6655443^NPI^^^MR
In-context excerpt 2 — PRD inside a REF^I12 with a primary care provider role and an effective date range:
MSH|^~&|EHR|SOUTHGROUP|EHR|ORTHOCTR|20260610123000||REF^I12^REF_I12|MSG00072|P|2.5.1
RF1|P^Pending^HL70283|R^Routine^HL70280|MED^Medical^HL70281|||REF20260610002|||20260610123000
PID|1||MRN551203^^^SOUTHGROUP^MR||Tan^Wei^L||19850620|M|||77 Cedar St^^Naperville^IL^60540^USA
PRD|PP^Primary Care Provider^HL70286|Lindqvist^Erik^J^^Dr^MD|55 Oak St^Suite 12^Naperville^IL^60540^USA|||^WPN^PH^^1^630^5550173|PH^Phone^HL70185|7781234^NPI^^^MR|20240101000000|20261231000000
PRD|RT^Referred to Provider^HL70286|Bianchi^Lucia^^^Dr^MD|210 State St^Floor 4^Chicago^IL^60604^USA|||^WPN^PH^^1^312^5550210|PH^Phone^HL70185|4456789^NPI^^^MR
FHIR mapping
There is no segment-level ConceptMap published in the v2-to-FHIR Implementation Guide for PRD, so the target is "Not mapped at the segment level." Conceptually, within a referral PRD maps across PractitionerRole and Practitioner: PRD-1 (Provider Role) corresponds to PractitionerRole.code, PRD-2 (Provider Name) and PRD-7 (Provider Identifiers) populate the Practitioner resource, and PRD-3/PRD-5 supply Practitioner.address and Practitioner.telecom. Any PRD transform must be defined locally and verified per interface because no normalized mapping is standardized.
Engine considerations
PRD has several repeating fields (PRD-1, PRD-2, PRD-3, PRD-5, PRD-7), so an engine must expand each into a list rather than assuming a single value. The required PRD-1 should be validated against HL70286 so referring versus referred-to roles are unambiguous before routing. The effective-date fields PRD-8 and PRD-9 are TS in v2.5.1; engines bridging to v2.7+ must convert these to DTM and reconcile precision. Because PRD is frequently followed by CTD segments, engines should treat each PRD plus its trailing CTDs as a provider group and preserve that grouping on re-serialization.
How Vorro parses and produces PRD
When Vorro parses PRD, each occurrence becomes a normalized provider record scoped to the referral from the surrounding REF message and PID. The repeating PRD-1 roles are captured as a list resolved against HL70286, PRD-2 names and PRD-3 addresses are decomposed into their XPN and XAD components, PRD-5 contact points are normalized into typed telecom entries, and PRD-7 identifiers are split into number and assigning-authority components. PRD-8 and PRD-9 are normalized into typed timestamps with explicit precision.
When Vorro produces PRD, it emits one segment per provider party in the referral, always populating PRD-1 with a coded role from HL70286 and writing normalized names, addresses, and contact points back into their XPN, XAD, and XTN structures. Identifiers are reassembled into PLN, and effective dates are formatted as TS for v2.5.1 targets. Any associated contact persons are emitted as following CTD segments so the provider grouping is preserved.
Related pages
- CTD Segment: Contact Data
- STF Segment: Staff Identification
- REF^I12 Message: Patient Referral
- AFF Segment: Professional Affiliation
- EDU Segment: Educational Detail
- LAN Segment: Language Detail
