Referral Profile¶
| Canonical | ../StructureDefinition/nexus-core-referral |
|---|---|
| Status | draft · 1.26.0 |
| Base | ServiceRequest (constraint) |
| Source | FSH · JSON |
Defines the Nexus EMR FHIR profile for referrals: a request that another clinician or service accept the patient, for consultation, second opinion, or ongoing management. Aligned to the pan-Canadian CA-eReC / Ontario eReferral contract, which is the shape Nexus already exchanges with Ocean. Distinct from NexusEmrCoreServiceRequest, which governs laboratory, imaging and procedure ORDERS and fixes intent to order.
Overview
Overview
A referral asks another clinician or service to take the patient on, for consultation, second opinion, or short- or longer-term management. This profile represents that request.
It is a sibling of
NexusEmrCoreServiceRequest, not a
refinement of it. Both are ServiceRequest profiles, and they differ on the elements that
carry the most meaning.
| Order | Referral (this profile) | |
|---|---|---|
intent |
order (fixed) |
proposal (fixed) |
category |
one of five base FHIR concepts (required) | receiving service or specialty (extensible) |
code |
1..1, code.text required |
0..1 |
performer |
not constrained | the receiving service |
Why intent is proposal
FHIR's intent records how much authority the requester has over whether the thing
happens. When a clinician orders a CBC, the lab performs it and the order carries
authorization. When a clinician refers a patient to cardiology, cardiology decides whether
to accept, and on what timeline. The referrer is making a proposal.
This is an alignment choice, not a universal rule. Base FHIR permits either value on a
referral, and HL7's own BSeR referral profile fixes order instead. What settles it here
is the contract Nexus is on: CA-eReC fixes intent = proposal, the Ontario eReferral
profile derives from CA-eReC, and every referral Nexus receives arrives as proposal.
Why category is the destination
On an order, category answers "what kind of thing is being ordered", and the five base
FHIR concepts cover it. On a referral it answers "who is receiving this" -- routing
information that decides which service the patient is sent to. No concept in that
five-member set can express it, which is why this profile exists at all.
The binding to
NexusReferralServiceType is extensible
rather than required, deliberately. Live Ontario traffic includes concepts outside it, and
a required binding would reject the referrals Nexus actually receives. Preserve the source
coding exactly as received and add the Nexus coding alongside it in the same
CodeableConcept; do not rewrite or drop the original.
Note that the value set is a union of healthcare services and provider specialties, not specialties alone. Several destinations a primary-care referral routinely targets exist in SNOMED CT only as service concepts. A picker that filters to the specialty hierarchy will silently lose them.
Why code is optional
The order profile requires code with code.text. A referral cannot: the Ontario
eReferral contract carries the routing information in category and sends no code at
all, so requiring it would make live inbound traffic non-conformant.
The legibility floor is preserved conditionally instead. The referral-code-has-text
invariant requires code.text when code is present. Referrals authored in Nexus
should populate both, from the reason for referral, so the receiving clinician can see what
is being asked without opening the letter.
code is deliberately left with the base R4 binding. CA-eReC binds it to Infoway's
InterventionCodeSubsetCare, which Infoway retired in April 2026 and marked "not recommended
for continued use"; this IG does not adopt a retired binding.
Referral Workflow
Referrals progress through states:
- Draft: Written, not yet sent
- Active: Sent, awaiting the consult
- On-hold: Waiting on something (imaging, bloodwork, patient contact)
- Completed: The consult happened
- Revoked: Declined or withdrawn
- Entered-in-error: Should be ignored
A worklist showing what has been sent and not yet answered reads status. priority
sorts it: a suspected-cancer referral and a routine dermatology referral do not wait in
the same queue.
Relationships
Referrals connect to:
- DocumentReference: The consult letter that comes back, pointing at the referral it answers
- Task: Work items tracking the referral through the practice
- Encounter: Clinical context when the referral was made
- Patient: Who is being referred
- Organization / PractitionerRole / HealthcareService: The receiving service, on
performer
See also
The Referrals guide page covers the relationship to the Ontario eReferral and pan-Canadian CA-eReC standards, what Ocean sends over the wire, and the coding guidance for referral destinations.
Terminology bindings
| Path | Strength | Value set |
|---|---|---|
ServiceRequest.status |
required | request-status |
ServiceRequest.intent |
required | request-intent |
ServiceRequest.category |
extensible | Referral Service Type Value Set |