HL7 PRD Provider Data
HL7 field reference PRD 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 |
|---|---|---|---|---|---|
| PRD.1 | Provider Role | Yes | Yes | CE | 0286 |
| PRD.2 | Provider Name | No | Yes | XPN | |
| PRD.3 | Provider Address | No | Yes | XAD | |
| PRD.4 | Provider Location | No | No | PL | |
| PRD.5 | Provider Communication Information | No | Yes | XTN | |
| PRD.6 | Preferred Method of Contact | No | No | CE | 0185 |
| PRD.7 | Provider Identifiers | No | Yes | PLN | |
| PRD.8 | Effective Start Date of Provider Role | No | No | TS | |
| PRD.9 | Effective End Date of Provider Role | No | No | TS |
PRD describes provider roles and contact details in referral and provider-related workflows.
The standard describes PRD this way: This segment will be employed as part of a patient referral message and its related transactions. The PRD segment contains data specifically focused on a referral, and it is inter-enterprise in nature. The justification for this new segment comes from the fact that we are dealing with referrals that are external to the facilities that received them. Therefore, using a segment such as the current PV1 would be inadequate for all the return information that may be required by the receiving facility or application. In addition, the PV1 does not always provide information sufficient to enable the external facility to make a complete identification of the referring entity. The information contained in the PRD segment will include the referring provider, the referred to provider, the referred to location or service, and the referring provider clinic address.
These segments describe clinical goals, problems, roles, referrals, requisitions, incidents, variances, and resource groupings that sit around the core patient/order/result traffic.
They are most useful when responsibilities, dates, identifiers, and status values are kept explicit. Otherwise they become narrative fragments that are hard to act on.
The v2.5.1 structures show PRD in RCI_I05 - Request for patient clinical information, RCL_I06 - Request/receipt of clinical data listing, REF_I12 - Patient referral, and RPA_I08 - Request for treatment authorization information, and 9 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.
PRD-1 identifies a person, provider, staff member, or contact involved in this care-plan or referral 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.
PRD-2 identifies a person, provider, staff member, or contact involved in this care-plan or referral 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.
PRD-3 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
PRD-4 identifies a person, provider, staff member, or contact involved in this care-plan or referral workflow. Use the structured name or provider datatype instead of flattening everything into display text.
PRD-5 identifies a person, provider, staff member, or contact involved in this care-plan or referral 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.
PRD-6 qualifies the care-plan or referral 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 0185. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
PRD-7 identifies the Provider Identifiers for this care-plan or referral 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.
PRD-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.
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.
PRD-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.
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.