HL7 Table HL70283: Referral Status

HL70283 carries the lifecycle state of a patient referral — accepted, pending, rejected, or expired — and rides primarily on the REF (Patient Referral) segment in the v2 RQI/RPI/RPL/RPR/RQA/PIN message families. The code set is small and HL7-defined; it has been stable across every v2 version that has supported referral messaging.

Purpose

HL70283 lets the receiving system tell the sender where the referral now sits in its workflow. A referring provider sends an RQI (Referral Request) with status P (Pending); the consultant responds with an RPI or RRI carrying A (Accepted) or R (Rejected). When a pending referral ages past its acceptance window without a response, the system can transition it to E (Expired).

The four codes are intentionally minimal. Workflows that need richer granularity (scheduled, completed, no-show, cancelled-by-patient) are expected to layer those distinctions onto other fields (PRT participation status, scheduling SCH segments) rather than extending HL70283.

Where it's used

REF-13 — historically labeled "Reason for Referral Cancel" in some profiles but used in production profiles to carry HL70283 referral status. Always check the profile.
Some implementer guides carry HL70283 on a Z-segment (ZRF or similar) or on RF1-1 (Referral Status) when present in the message structure.
PRT segments associated with the referral may also restate the status for the participating party.

Because the precise field placement varies by message family and IG, the table is best located by code system OID rather than by field number.

Code list

Code	Display	Comment/Description
A	Accepted	Receiving provider has accepted the referral; the patient is now their responsibility for the referred care.
E	Expired	The referral aged past its validity window without acceptance and is no longer actionable.
P	Pending	The referral has been received but not yet acted on; awaiting acceptance, rejection, or scheduling.
R	Rejected	Receiving provider has declined the referral; the referring provider must redirect.

Code system OID

OID: 2.16.840.1.113883.18.128
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0283

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values.

HL7-defined vs user-defined

HL70283 is HL7-defined. The four single-character codes are normative. Sites occasionally extend HL70283 with values like S (Scheduled), C (Completed), or X (Cancelled), but those are non-conformant — scheduling state belongs on SCH, and completion belongs on the encounter or on a downstream ORU. Keeping HL70283 narrow lets receivers treat referral lifecycle as a simple four-state machine.

Version differences

v2.3.1 — HL70283 introduced alongside the referral message families.
v2.4 – v2.6 — No changes; the set stayed at four codes.
v2.7 — Referral status fields transitioned to CWE in many profiles, allowing OID metadata to accompany the HL70283 code.
v2.8 – v2.8.1 — Set frozen at four codes; no further additions.

The table's stability reflects its narrow scope. Modern referral interoperability (FHIR ServiceRequest, Task, Da Vinci PAS) has richer status vocabularies, but the v2 wire format keeps four codes.

Common mistakes

Sending Accepted or pending instead of the single-character code. Even when the field is CWE, CWE.1 is the code (A), and the display word belongs in CWE.2.
Treating E (Expired) as a permanent rejection. Expired referrals can often be resubmitted; rejected referrals usually cannot without a new clinical justification.
Confusing HL70283 (lifecycle) with HL70281 (Referral Disposition). Disposition records what happened clinically (assumed care, returned to referring); status records workflow state.
Extending HL70283 with vendor codes for scheduled or completed. Conformant receivers will quarantine the message; carry scheduling state on SCH and completion on the encounter feed.
Sending lowercase. HL70283 codes are case-sensitive uppercase.

Examples

A pending referral request:

MSH|^~&|EHR|CLINIC|EHR|CONSULT|20260601120000||REF^I12^REF_I12|MSG00100|P|2.5.1
PID|1||10456^^^MRN^MR||DOE^JANE||19850412|F
RF1|P^Pending^HL70283||||REF-2026-0001

The consultant's acceptance response:

MSH|^~&|EHR|CONSULT|EHR|CLINIC|20260602093000||REF^I12^REF_I12|MSG00101|P|2.5.1
PID|1||10456^^^MRN^MR||DOE^JANE||19850412|F
RF1|A^Accepted^HL70283||||REF-2026-0001

A rejection with reason:

RF1|R^Rejected^HL70283|UNAVAIL^Provider unavailable|||REF-2026-0002

Translated to a FHIR Task representing the referral workflow:

{
  "resourceType": "Task",
  "id": "ref-2026-0001",
  "status": "accepted",
  "intent": "order",
  "focus": { "reference": "ServiceRequest/sr-2026-0001" },
  "for": { "reference": "Patient/10456" },
  "code": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v2-0283",
      "code": "A",
      "display": "Accepted"
    }]
  }
}

The FHIR Task.status enum carries the lifecycle, and the original HL70283 code rides along on Task.code so the round-trip back to v2 is exact.

FHIR mapping

The v2-to-FHIR IG models referrals as either ServiceRequest (the clinical ask) or Task (the workflow around it). HL70283 maps to:

HL7 v2 (HL70283)	FHIR Task.status	FHIR ServiceRequest.status
A	`accepted`	`active`
E	`failed` (or `cancelled`)	`revoked`
P	`requested` / `received`	`active`
R	`rejected`	`revoked`

Because the FHIR enums are richer (in-progress, on-hold, ready, draft), implementers should preserve the original HL70283 code as a Coding extension so an outbound v2 channel can reconstruct the four-state value without guessing.

Engine considerations

Single-character validation — HL70283 codes are one character; engines should reject longer payloads or normalize them with a warning.
Profile-specific placement — REF-13, RF1-1, and various Z-segments all carry HL70283 depending on the profile. Engines should locate the table by code system OID rather than hard-coding a field path.
Idempotent status transitions — A referral may legitimately move through P → A → (clinical completion elsewhere) or P → R or P → E. Engines should not silently overwrite an A with a later P; out-of-order updates indicate a sender bug worth surfacing.
CWE upgrade path — In v2.7+ profiles the carrying field is typically CWE; CWE.14 carries the OID 2.16.840.1.113883.18.128. Engines must handle both pre- and post-v2.7 shapes.
Round-trip preservation — When mapping to FHIR Task.status or ServiceRequest.status, store the original HL70283 code as an extension so the v2 outbound channel can restore the four-state value cleanly.

How Vorro handles HL70283

Vorro validates referral-status fields across the REF, RF1, and PRT segments against the four HL70283 codes on ingest. Values that match are forwarded to all downstream channels untouched. Locally extended codes (S for scheduled, C for completed) are routed to the terminology curation queue, where they typically remap to one of the four canonical codes plus an additional structured field on a downstream segment (SCH, encounter feed) so workflow state is not lost.

On outbound, Vorro emits HL70283 as CE for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations. When converting to FHIR, Vorro emits Task.status (or ServiceRequest.status, depending on profile choice) and preserves the raw HL70283 Coding on a Task.code or ServiceRequest extension so the round-trip back to v2 reconstructs the referral status field byte-for-byte.

Sources

← Back to HL7 v2 Guide