HL7 REF Messages: Patient Referral

HL7 REF messages carry patient referrals — the request from one provider to another to evaluate, treat, or take over the care of a patient, together with the clinical and administrative context the referred-to provider needs to act on it. A REF message is sent from the referring provider's system to the referred-to provider's system, and it bundles the referral itself with the patient, the providers on both ends, the diagnoses and procedures behind the request, and any supporting observations. This page explains what a REF message represents, the trigger events that carry it, every segment the message can contain and what each one holds, and how a referral relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What a REF message represents

A REF message — REF stands for Patient Referral — communicates a referral between two providers, typically across enterprise boundaries. The core of the message is the RF1 segment, which carries the referral itself: its status, priority, type, category, the originating and external referral identifiers, the effective and expiration dates, and the reason for the referral. Around that sit the two providers — the referring provider and the referred-to provider — each described by a PRD Provider Data segment, with CTD Contact Data carrying the people to reach within each.

The sender is the referring provider's application, and the receiver is the referred-to provider's application. Because a referral commonly crosses organizational lines, the message deliberately carries inter-enterprise provider detail that an ordinary visit segment does not: the PRD segment exists precisely to identify the referring provider, the referred-to provider, the location where services will be delivered, and the clinic contacts — the data needed to complete a referral between two separate organizations. The RF1, not the surrounding clinical segments, is the authoritative record of the referral request itself.

When a REF message is sent

A REF message is sent when a provider refers a patient to another provider, and when that referral subsequently changes, is cancelled, or its status is requested. The clinical and administrative context — patient, insurance, diagnoses, procedures, and observations — travels with the referral so the receiver has what it needs without a separate lookup.

Trigger events

In HL7 v2.5.1, Chapter 11 (Patient Referral) defines four trigger events for the REF message, and all four share the same abstract message structure, REF_I12:

REF^I12 – Patient referral.
REF^I13 – Modify patient referral.
REF^I14 – Cancel patient referral.
REF^I15 – Request patient referral status.

Because all four events reuse the same REF_I12 structure, the receiver's handling turns on the trigger code in MSH-9 together with the referral status and identifiers in RF1 — whether this is a new referral, a change to one, a cancellation, or a status request. Each REF event has a corresponding RRI (Return Referral Information) response message that carries the same structure back to the originator.

Integration topology

The diagram shows the referring provider's system sending a referral through the integration engine to the referred-to provider's system.

{{diagram: referring provider system → REF message → integration engine → referred-to provider system}}

Typical senders: the referring provider's EHR or practice-management system.

Typical receivers: the referred-to provider's EHR, specialty or consult application, or referral-management system.

Direction: a directed request from the referring provider to the referred-to provider, with an RRI response returned to the originator.

Segments in a REF message

The REF_I12 message is organised into groups. After the header, the optional AUTHORIZATION_CONTACT group (AUT with an optional CTD) carries authorization for the referral, and the required, repeating PROVIDER_CONTACT group (PRD with optional repeating CTD) carries each provider and its contacts. The patient and financial segments follow, then the PROCEDURE, OBSERVATION, and PATIENT_VISIT groups. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

Segment	Description
`MSH`	Message Header. Opens every REF message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in `MSH-9` (for example `REF^I12^REF_I12`), carries the message control id in `MSH-10`, and pins the HL7 version. Receivers route on `MSH-9` and deduplicate on `MSH-10`.
`[{SFT}]`	Software Segment. Identifies the software product behind the sender — vendor, product, and version. Optional and repeating; useful when referral behaviour differs across sender releases.
`[RF1]`	Referral Information. The core of the message. It carries the referral status in `RF1-1`, priority in `RF1-2`, type in `RF1-3`, disposition in `RF1-4`, category in `RF1-5`, the originating referral identifier in `RF1-6`, the effective and expiration dates in `RF1-7` and `RF1-8`, the process date in `RF1-9`, the referral reason in `RF1-10`, and the external referral identifier in `RF1-11` — the identifier assigned by the referred-to application. Optional in the abstract structure but the defining segment of a referral.
`[AUT]`	Authorization Information. Opens the optional AUTHORIZATION_CONTACT group. Carries the authorization or pre-certification behind the referral — the authorizing payer or plan, the authorization number, and its dates.
`[CTD]`	Contact Data. Within the authorization group, the contact to reach about the authorization — role in `CTD-1`, name in `CTD-2`, address, location, and communication details.
`PRD`	Provider Data. Opens the required, repeating PROVIDER_CONTACT group, and is the segment that makes REF a referral. Each `PRD` describes one provider on the referral — the role in `PRD-1` (referring provider, referred-to provider) , the name in `PRD-2`, address, location, communication information, and the provider and organization identifiers. The group repeats, so one `PRD` names the referring provider and another the referred-to provider.
`[{CTD}]`	Contact Data. The contacts within each provider — office manager, billing, scheduling — with role, name, location, and communication details. Optional and repeating within the PROVIDER_CONTACT group.
`PID`	Patient Identification. Identifies the patient being referred — the identifier list in `PID-3`, the name in `PID-5`, birth date, and sex. Required.
`[{NK1}]`	Next of Kin / Associated Parties. Relatives, guardians, and emergency contacts for the referred patient, with relationship and contact details. Optional and repeating.
`[{GT1}]`	Guarantor. The financially responsible party for the referred care — name, relationship, address, and employer. Optional and repeating.
`[{IN1` `[IN2] [IN3]}]`	Insurance. Opens the optional, repeating INSURANCE group. `IN1` carries one coverage — payer, plan, policy and group number, and subscriber relationship — with `IN2` adding subscriber and employment detail and `IN3` adding certification. Multiple groups establish primary, secondary, and tertiary coverage in order.
`[ACC]`	Accident. Accident detail when the referral follows an injury — date and time, location, code, and auto- or job-related indicators.
`[{DG1}]`	Diagnosis. The diagnoses behind the referral, coded in ICD-10, SNOMED CT, or a local system, with priority and onset date. Optional and repeating.
`[{DRG}]`	Diagnosis-Related Group. A DRG assigned to the referred care for case-mix and reimbursement, with grouper version and severity. Optional and repeating.
`[{AL1}]`	Patient Allergy Information. One allergy per segment — type, severity, code, reaction, and onset — carried with the referral. Optional and repeating.
`[{PR1` `[AUT` `[CTD]]}]`	Procedures. Opens the optional, repeating PROCEDURE group. `PR1` carries a procedure relevant to the referral — code, date, and type — with an optional nested `AUT` and `CTD` for procedure-specific authorization and its contact.
`[{OBR` `[{NTE}] [{OBX` `[{NTE}]}]}]`	Observation Request / Result. Opens the optional, repeating OBSERVATION group. `OBR` introduces a set of supporting observations, each with optional `NTE` notes, and the nested `OBX` segments carry the observation values — vitals, results, or clinical findings supplied to support the referral — each with their own optional `NTE` notes.
`[PV1` `[PV2]]`	Patient Visit. The optional PATIENT_VISIT group. `PV1` describes the encounter the referral relates to — patient class, location, and providers — with `PV2` adding admit reason and expected dates.
`[{NTE}]`	Notes and Comments. Message-level notes that apply to the referral as a whole. Optional and repeating.

[ ] = optional, { } = repeating

The PROVIDER_CONTACT group from PRD onward repeats, so a single REF message names both the referring and the referred-to provider, each with its own contacts. The canonical segment pages carry the full field-by-field detail.

Sample REF message

Note. Constructed for illustration. Patient identifiers, referral numbers, dates, and names are fictional.

MSH|^~&|REFERRAL|MERCYGEN|CONSULT|CARDIOCTR|202006031000||REF^I12^REF_I12|MSG00021|P|2.5.1
RF1|P^Pending^HL70283|S^Stat^HL70280|MED^Medical^HL70281|||REF20060601^^MERCYGEN|20200603|20200903||C^Consultation^HL70336
PRD|RP^Referring Provider^HL70286|SMITH^JANE^A^^^MD|100 MAIN ST^^SPRINGFIELD^IL^62704|||^^^^^555^5550100||||1234^^^MERCYGEN^NPI
PRD|RT^Referred-to Provider^HL70286|LEE^ROBERT^B^^^MD|200 HEART WAY^^SPRINGFIELD^IL^62704|||^^^^^555^5550200||||5678^^^CARDIOCTR^NPI
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
DG1|1|ICD-10|I20.9^Angina pectoris, unspecified^I10|ANGINA|20200603|A
PV1|1|O|CLINIC^^^MERCYGEN

What this sample shows

The REF^I12 in MSH-9 marks a new patient referral. The RF1 carries the referral itself: status pending (RF1-1), stat priority (RF1-2), a medical referral type (RF1-3), the originating referral identifier REF20060601 (RF1-6), an effective date and expiration date (RF1-7, RF1-8), and a consultation reason (RF1-10). The two PRD segments name the providers on each end — the referring provider SMITH at MercyGen (RP) and the referred-to provider LEE at the cardiology center (RT), each with an NPI in PRD-7. PID identifies the referred patient by medical record number MR12345, DG1 carries the angina diagnosis behind the referral, and PV1 places it against an outpatient encounter.

Working with REF messages

Read the referral from RF1, not the surrounding segments

The referral's status, priority, type, dates, and identifiers live in RF1. The patient, diagnosis, and visit segments are context; the referral request itself is RF1. Drive handling from the trigger event in MSH-9 and the status in RF1-1 rather than inferring intent from the clinical segments.

Distinguish the two providers by role

Both the referring and the referred-to provider appear as repeating PRD segments, distinguished only by the provider role in PRD-1. Read the role to tell them apart rather than assuming the first PRD is always the referring provider — confirm against the role code set the partner uses.

Track the two referral identifiers

RF1-6 carries the originating referral identifier assigned by the referring application, and RF1-11 carries the external referral identifier assigned by the referred-to application in its response. Correlate a referral and its RRI response across the two systems using both identifiers rather than relying on a single one.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the originating referral identifier in RF1-6 as the natural business key for the referral. A modify (I13) or cancel (I14) event carries the same RF1-6 as the original I12, so key on it to apply the change to the right referral rather than creating a new one.

Vendor variance. Many REF segments and groups are optional, so partners differ widely in how much context they include — some send only RF1, PRD, and PID, while others attach full diagnosis, procedure, and observation groups. Confirm a partner's field usage and code sets against their interface specification rather than assuming the base standard.

FHIR equivalent

A patient referral corresponds conceptually to the FHIR ServiceRequest resource — often paired with a Task to track fulfilment — with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide publishes no message map for REF_I12 (its message maps cover only a subset of ADT events, OML_O21, ORM_O01, VXU_V04, ORU_R01, MDM_T02, and SIU_S12) and no ConceptMap for the RF1 referral segment. A FHIR representation produced from a REF message is therefore mapped manually, taking the referral request from RF1, the providers from the PRD segments, the patient from PID, and the supporting clinical context from the diagnosis, procedure, and observation segments.

Common pitfalls

Pitfall. Assuming the first PRD is the referring provider. The referring and referred-to providers are distinguished by the role code in PRD-1, not by order; read the role.

Pitfall. Treating a modify or cancel as a new referral. REF^I13 and REF^I14 reuse the REF_I12 structure and carry the same originating referral identifier in RF1-6; key on it so the event updates or reverses the existing referral.

Pitfall. Assuming a fixed date-time precision. Senders may stamp RF1-7, RF1-8, and RF1-9 as YYYYMMDD or as a full timestamp with an offset; do not assume a timezone — normalize on ingest.

How Vorro handles REF messages

Vorro ingests the referral feed over MLLP or another transport, deduplicates on MSH-10, routes by the trigger event in MSH-9, and delivers each referral to the referred-to destination in the format that system expects. Vorro reads the referral status, dates, and identifiers from RF1, separates the referring and referred-to providers by the role in each PRD, keys modify and cancel events to the originating referral identifier, and, where a FHIR destination is configured, maps the referral to a ServiceRequest — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

RQI — request for insurance information, used alongside referrals to verify a patient's coverage.
RPI — return patient information, a response carrying patient and insurance detail.
ADT — the patient administration feed that establishes the patient context a referral assumes.

Sources

HL7 v2.5.1 Chapter 11 — Patient Referral (hl7.eu standard mirror) — confirms trigger events I12–I15 and the REF_I12 abstract structure
HAPI HL7v2 v2.5.1 REF_I12 message structure — confirms the v2.5.1 segment and group composition
HAPI HL7v2 v2.5.1 RF1 segment — confirms RF1 has 11 fields in v2.5.1
HL7 v2 RF1 segment definition (hl7.eu mirror)
HL7 v2 PRD segment definition (hl7.eu mirror)
HL7 v2 CTD segment definition (hl7.eu mirror)
HL7 v2-to-FHIR IG — message maps index — confirms no message map for REF_I12
HL7 v2-to-FHIR IG — segment maps index
HL7 Messaging Standard Version 2.5.1 product brief </content>

</invoke>

← Back to HL7 v2 Guide