HL7 RF1 Referral Information
HL7 field reference RF1 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 |
|---|---|---|---|---|---|
| RF1.1 | Referral Status | No | No | CE | 0283 |
| RF1.2 | Referral Priority | No | No | CE | 0280 |
| RF1.3 | Referral Type | No | No | CE | 0281 |
| RF1.4 | Referral Disposition | No | Yes | CE | 0282 |
| RF1.5 | Referral Category | No | No | CE | 0284 |
| RF1.6 | Originating Referral Identifier | Yes | No | EI | |
| RF1.7 | Effective Date | No | No | TS | |
| RF1.8 | Expiration Date | No | No | TS | |
| RF1.9 | Process Date | No | No | TS | |
| RF1.10 | Referral Reason | No | Yes | CE | 0336 |
| RF1.11 | External Referral Identifier | No | Yes | EI |
RF1 carries referral information such as referral status, type, reason, dates, and disposition.
The standard describes RF1 this way: This segment represents information that may be useful when sending referrals from the referring provider to the referred-to provider.
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 RF1 in REF_I12 - Patient referral, RPA_I08 - Request for treatment authorization information, RQA_I08 - Request for treatment authorization information, and RRI_I12 - Patient referral. 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.
RF1-1 tells the receiver the state of this care-plan or referral workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0283 or the narrower table in the local profile.
RF1-2 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 0280. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
RF1-3 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 0281. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
RF1-4 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 0282. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
RF1-5 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 0284. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
RF1-6 identifies the Originating Referral Identifier 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.
RF1-7 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.
RF1-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.
RF1-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.
RF1-10 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 0336. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
RF1-11 identifies the External Referral Identifier 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.