The RF1 (Referral Information) segment carries the metadata for a patient referral as a whole — its status, priority, type, disposition, category, originating and external identifiers, and the dates that bound its lifecycle. It is the header segment of a referral exchange: one RF1 describes the referral itself, while the surrounding PRD segments describe the providers involved and PID describes the patient being referred.
Unlike provider-level segments such as PRD and CTD that repeat per party, RF1 appears once per referral message and is the anchor that ties together the referral identifier, its workflow state, and the dates on which it was issued, becomes effective, expires, or is processed.
Purpose
The purpose of RF1 is to describe the referral as a business object so the receiving system can act on it consistently. RF1-1 (Referral Status) tells the receiver where the referral sits in its workflow, RF1-2 (Referral Priority) and RF1-3 (Referral Type) tell it how urgently and for what kind of care it is being made, RF1-4 and RF1-5 categorize the disposition and clinical category, and RF1-6 carries the originating sender's referral identifier — the single value used to correlate acknowledgements, updates, and cancellations.
RF1 is the routing and lifecycle header of a referral and is paired with one or more PRD segments that name the providers and, optionally, CTD segments that elaborate contact persons for those providers.
Used in
RF1 is used in the REF message family — specifically the REF^I12 patient referral message. Within that message RF1 follows the MSH header and precedes the PID (Patient Identification) segment and the PRD provider segments. The REF message communicates a patient referral from one provider or organization to another, and RF1 carries the metadata that scopes the entire referral.
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/RF1.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 |
|---|---|---|---|---|---|---|---|
| RF1-1 | Referral Status | ce | — | R | — | HL70283 | Workflow state of the referral |
| RF1-2 | Referral Priority | ce | — | O | — | HL70280 | Urgency of the referral |
| RF1-3 | Referral Type | ce | — | O | — | HL70281 | Clinical kind of referral being made |
| RF1-4 | Referral Disposition | ce | — | O | Y | HL70282 | How the referral is to be dispositioned |
| RF1-5 | Referral Category | ce | — | O | — | HL70284 | Setting category of the referral |
| RF1-6 | Originating Referral Identifier | ei | — | R | — | — | Sender's unique identifier for this referral |
| RF1-7 | Effective Date | ts | — | O | — | — | Date the referral becomes effective |
| RF1-8 | Expiration Date | ts | — | O | — | — | Date the referral expires |
| RF1-9 | Process Date | ts | — | O | — | — | Date the referral was processed |
| RF1-10 | Referral Reason | ce | — | O | Y | HL70336 | Coded reason the referral is being made |
| RF1-11 | External Referral Identifier | ei | — | O | Y | — | Receiver's or external system's identifier |
Most-used fields
RF1-1 (Referral Status) and RF1-6 (Originating Referral Identifier) are the two values every referral must carry — the first because it drives downstream workflow and the second because it correlates the referral across systems. RF1-2 (Priority) and RF1-3 (Type) are heavily used by triage and scheduling logic to route the referral to the right specialty and queue. RF1-7, RF1-8, and RF1-9 (Effective, Expiration, and Process dates) are used by claims and authorization systems to bound the referral's validity. RF1-10 (Referral Reason) and RF1-11 (External Referral Identifier) commonly carry the clinical justification and the receiving organization's tracking number once the referral has been accepted.
Version differences (2.3 to 2.8.2)
RF1 has carried its eleven-field structure since HL7 v2.4, with RF1-10 (Referral Reason) and RF1-11 (External Referral Identifier) added relative to earlier definitions. The structure is stable through v2.8.2. The principal evolution is in data types: RF1-7, RF1-8, and RF1-9 are TS in v2.5.1 and were realigned toward DTM in v2.7 and later as HL7 migrated time-stamp fields. The CE fields RF1-1 through RF1-5 and RF1-10 gained additional components (notably alternate coding system version IDs) in later versions, and CE itself is replaced by CWE in some downstream variants. No RF1 field was added, removed, or renumbered after v2.4, but transforms that move between v2.5.1 and v2.7+ must account for the TS-to-DTM change in the date fields.
Common mistakes
The most common mistake is omitting RF1-6 (Originating Referral Identifier) or reusing the message control ID from MSH-10 in its place — the two are distinct, and receivers correlate referral updates by RF1-6, not by MSH-10. Another is sending an uncoded value in RF1-1 (Referral Status) so receivers cannot tell a pending referral from an accepted or cancelled one. Implementers also confuse RF1-4 (Referral Disposition, which repeats) with RF1-5 (Referral Category, which does not), packing multiple categories into one field. Finally, the effective and expiration dates RF1-7 and RF1-8 are frequently sent at day precision when the receiving system needs at least minute precision to enforce an authorization window — engines bridging to v2.7+ DTM should keep the highest available precision.
Examples
Minimal RF1 (status and originating identifier only):
RF1|P^Pending^HL70283|||||REF20260610001
Fully-populated RF1:
RF1|A^Accepted^HL70283|R^Routine^HL70280|MED^Medical^HL70281|RTF^Return to Referring^HL70282|AMB^Ambulatory^HL70284|REF20260610001^NORTHCLINIC^L|20260610120000|20260910120000|20260611080000|CARD^Cardiology Evaluation^HL70336|REF-EXT-44219^CARDIOGROUP^L
Annotated breakdown:
RF1|A^Accepted^HL70283|R^Routine^HL70280|MED^Medical^HL70281|RTF^Return to Referring^HL70282|AMB^Ambulatory^HL70284|REF20260610001^NORTHCLINIC^L|20260610120000|20260910120000|20260611080000|CARD^Cardiology Evaluation^HL70336|REF-EXT-44219^CARDIOGROUP^L
| | | | | | | | | | |
| | | | | | | | | | +--> RF1-11 External Referral Identifier (EI, repeats)
| | | | | | | | | +-----------------------------------> RF1-10 Referral Reason (CE, repeats) = Cardiology Evaluation
| | | | | | | | +------------------------------------------------------> RF1-9 Process Date (TS)
| | | | | | | +-----------------------------------------------------------------------> RF1-8 Expiration Date (TS)
| | | | | | +----------------------------------------------------------------------------------------> RF1-7 Effective Date (TS)
| | | | | +-------------------------------------------------------------------------------------------------------------------> RF1-6 Originating Referral Identifier (EI)
| | | | +----------------------------------------------------------------------------------------------------------------------------------------> RF1-5 Referral Category (CE) = Ambulatory
| | | +---------------------------------------------------------------------------------------------------------------------------------------------------------------------> RF1-4 Referral Disposition (CE, repeats)
| | +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> RF1-3 Referral Type (CE) = Medical
| +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> RF1-2 Referral Priority (CE) = Routine
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> RF1-1 Referral Status (CE) = Accepted
In-context excerpt 1 — RF1 inside a REF^I12 patient referral message, after MSH and before PID and the PRD 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||AMB^Ambulatory^HL70284|REF20260610001^NORTHCLINIC^L|20260610120000|20260910120000||CARD^Cardiology Evaluation^HL70336
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 — RF1 inside a REF^I12 communicating an accepted referral with an external identifier and a process date assigned by the receiver:
MSH|^~&|EHR|CARDIOGROUP|EHR|NORTHCLINIC|20260611080500||REF^I12^REF_I12|MSG00088|P|2.5.1
RF1|A^Accepted^HL70283|R^Routine^HL70280|MED^Medical^HL70281|RTF^Return to Referring^HL70282|AMB^Ambulatory^HL70284|REF20260610001^NORTHCLINIC^L|20260610120000|20260910120000|20260611080000|CARD^Cardiology Evaluation^HL70336|REF-EXT-44219^CARDIOGROUP^L
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
FHIR mapping
There is no segment-level ConceptMap published in the v2-to-FHIR Implementation Guide for RF1, so the target is "Not mapped at the segment level." Conceptually, RF1 maps to a ServiceRequest resource representing the referral: RF1-1 (Referral Status) corresponds to ServiceRequest.status, RF1-2 (Referral Priority) to ServiceRequest.priority, RF1-3 and RF1-5 inform ServiceRequest.category, RF1-6 and RF1-11 populate ServiceRequest.identifier, RF1-7 and RF1-8 bound ServiceRequest.occurrencePeriod, and RF1-10 contributes to ServiceRequest.reasonCode. Any RF1 transform must be defined locally and verified per interface because no normalized mapping is standardized.
Engine considerations
RF1 carries several repeating fields (RF1-4, RF1-10, RF1-11), so an engine must expand each into a list rather than assuming a single value. The required RF1-1 and RF1-6 should be validated before routing — a missing originating identifier defeats correlation, and an uncoded status defeats workflow logic. The date fields RF1-7, RF1-8, and RF1-9 are TS in v2.5.1; engines bridging to v2.7+ must convert these to DTM and reconcile precision so authorization windows are not truncated. RF1 should be treated as the referral-scope header, with subsequent PID and PRD segments interpreted as belonging to the referral RF1 describes.
How Vorro parses and produces RF1
When Vorro parses RF1, it materializes a normalized referral record keyed by RF1-6 (Originating Referral Identifier) with secondary correlation through RF1-11 once a receiver has assigned an external identifier. The coded fields RF1-1 through RF1-5 and RF1-10 are resolved against their HL7 tables (HL70283, HL70280, HL70281, HL70282, HL70284, HL70336) so downstream logic operates on canonical codes rather than free text. RF1-7, RF1-8, and RF1-9 are normalized into typed timestamps with explicit precision, and the repeating dispositions, reasons, and external identifiers are captured as lists.
When Vorro produces RF1, it emits exactly one segment per referral, always populating RF1-1 with a coded status from HL70283 and RF1-6 with the originating identifier guaranteed unique within the sending namespace. Repeating dispositions, reasons, and external identifiers are written back as HL7 repetitions. Dates are formatted as TS for v2.5.1 targets and converted to DTM when the destination is v2.7+.
Related pages
- PRD Segment: Provider Data
- PID Segment: Patient Identification
- REF^I12 Message: Patient Referral
- CTD Segment: Contact Data
