HL7 REF_I12 (Patient Referral) | Integration Soup HL7 Reference Guide

HL7 REF_I12 Patient Referral

A provider-to-provider referral packet for a specific patient.

HL7 message structure REF_I12 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
RF1	Referral Information	No	No
REF_I12.AUTHORIZATION_CONTACT	Authorization Contact group	No	No
AUT	Authorization Information	Yes	No
CTD	Contact Data	No	No
REF_I12.PROVIDER_CONTACT	Provider Contact group	Yes	Yes
PRD	Provider Data	Yes	No
CTD	Contact Data	No	Yes
PID	Patient Identification	Yes	No
NK1	Next of Kin / Associated Parties	No	Yes
GT1	Guarantor	No	Yes
REF_I12.INSURANCE	Insurance group	No	Yes
IN1	Insurance	Yes	No
IN2	Insurance Additional Information	No	No
IN3	Insurance Additional Information, Certification	No	No
ACC	Accident	No	No
DG1	Diagnosis	No	Yes
DRG	Diagnosis Related Group	No	Yes
AL1	Patient Allergy Information	No	Yes
REF_I12.PROCEDURE	Procedure group	No	Yes
PR1	Procedures	Yes	No
REF_I12.AUTCTD_SUPPGRP2	Autctd Suppgrp2 group	No	No
AUT	Authorization Information	Yes	No
CTD	Contact Data	No	No
REF_I12.OBSERVATION	Observation group	No	Yes
OBR	Observation Request	Yes	No
NTE	Notes and Comments	No	Yes
REF_I12.RESULTS_NOTES	Results Notes group	No	Yes
OBX	Observation/Result	Yes	No
NTE	Notes and Comments	No	Yes
REF_I12.PATIENT_VISIT	Patient Visit group	No	No
PV1	Patient Visit	Yes	No
PV2	Patient Visit - Additional Information	No	No
NTE	Notes and Comments	No	Yes

REF_I12 sends a patient referral from one healthcare provider to another. It can include demographics, provider contacts, insurance, authorization, diagnoses, allergies, procedures, observations, visit context, and notes. The response side is RRI_I12.

This is a broad message, so the local profile matters. A lightweight referral might only carry patient identity, referring provider, reason, and a few observations. A richer referral packet may include authorization and clinical history. Do not let the optionality fool you into sending everything just because the structure allows it.

A small REF I12 example

MSH|^~\&|REFERRAL|CITYCLINIC|ORTHO|CITYHOSP|20260718111500||REF^I12^REF_I12|REF120001|P|2.5.1 RF1|A|R^Routine^HL70280|ORTHO^Orthopedic referral^L|20260718111500|20260801100000 AUT|1|PAYERHUB|CITYCARE|AUTH20260718|20260718110005|CONSULT^Specialist consultation^L|APPROVED^Approved^L CTD|PR|Auth^Ava|PO Box 77^^Auckland^^1140^NZ|^WPN^PH^^64^9^5557070 PRD|RP|Nguyen^Mara^^^Dr^MD|88 Clinic Road^^Auckland^^1010^NZ|^^^CITYCLINIC|555555 CTD|PR|Care^Cara|88 Clinic Road^^Auckland^^1010^NZ|^WPN^PH^^64^9^5551000 PRD|RT|Orthopedic Clinic^City Hospital|1 Hospital Way^^Auckland^^1010^NZ|^^^ORTHO|ORTHO PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F|||12 High Street^^Auckland^^1010^NZ NK1|1|Smith^Alex|SPO^Spouse^HL70063|12 High Street^^Auckland^^1010^NZ|^PRN^CP^^64^21^5557777 IN1|1|PLAN77|CITYCARE|CityCare Health Plan|PO Box 77^^Auckland^^1140^NZ|||||Smith^Jane^Anne|SEL DG1|1|I10|M25.561^Pain in right knee^I10|Pain in right knee|20260717103000|A AL1|1||PEN^Penicillin^L|MO|Rash PR1|1|CPT|99243^Office consultation^CPT|Specialist consultation|20260801100000 OBR|1|REF120001^REFERRAL||KNEE-HIST^Knee referral history^L|||20260718111500 OBX|1|TX|CLINHIST^Clinical history^L||Persistent knee pain after sports injury, x-ray negative.||||||F PV1|1|O|ORTHO^CLINIC^1^CITYHOSP NTE|1||Please review and advise treatment plan.

What workflow it represents

The sender is the referring provider or a referral system acting for that provider. The receiver is the referred-to provider, clinic, hospital service, or referral management hub. The receiving side usually creates a referral record, worklist item, appointment request, or review queue.

The message should make the reason for referral obvious. If the receiver has to infer the clinical question from a pile of loosely related diagnoses and notes, the interface will create manual follow-up.

How to read the structure

MSH identifies the referral. RF1 carries referral status, priority, type, dates, and related referral information. AUT and CTD can carry authorization contact details.

The provider-contact group repeats with PRD and CTD for referring, referred-to, primary care, or other roles. PID, NK1, IN1, DG1, AL1, PR1, OBR, OBX, and PV1 carry the patient, coverage, clinical, procedure, observation, and encounter context.

Implementation traps

The main trap is sending a referral with plenty of data but no clear ask. Use RF1, PRD roles, diagnoses, procedures, and OBX/NTE notes to make the requested service and reason visible.

HL7 notes that PV1/PV2 in REF identify the visit or encounter that generated the referral. They should not be abused as a way to propose a future visit created by the referral.

Reference notes

The HL7 v2+ patient referral chapter describes I12 as a provider-to-provider referral for a specific patient that may contain demographics, procedures with authorizations, and relevant clinical information. It also notes the special care needed when interpreting PV1/PV2 in REF and RRI messages.