Skip to content

Referrals

A referral asks another clinician or service to take the patient on. Nexus profiles it as NexusCoreReferral, a ServiceRequest profile that is deliberately separate from NexusEmrCoreServiceRequest, which governs laboratory, imaging and procedure orders.

This page explains why there are two profiles, how the referral profile relates to the Canadian and Ontario standards, and what to do about the places where live traffic and the published standards disagree.

Two profiles, not one

The two are not variations on a theme. They differ on the element that carries the most meaning:

Order (NexusEmrCoreServiceRequest) Referral (NexusCoreReferral)
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

intent is the substantive difference. FHIR uses it to record how much authority the requester has over whether the thing happens. When a clinician orders a CBC, the lab performs it; 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, not issuing an instruction.

category follows from that. On an order it answers "what kind of thing is being ordered" and the five base FHIR concepts (Laboratory procedure, Imaging, Counselling, Education, Surgical procedure) cover it. On a referral it answers "who is receiving this", which is routing information, and no concept in that five-member set can express it.

Why the order profile is not simply relaxed

A published profile's constraints are promises other systems have already built against. Dropping the fixed intent = order from the order profile would silently weaken a guarantee every existing laboratory and imaging consumer relies on, in order to accommodate a resource class that profile was never shaped for. Adding a sibling costs nothing to existing consumers and leaves both guarantees intact.

For the same reason the referral profile derives from base R4 ServiceRequest, not from the order profile. A derived profile may tighten its parent but never loosen it, so a fixed order and a required five-concept binding cannot be recovered downstream.

Relationship to the Canadian and Ontario standards

Referrals are one of the better-standardised exchanges in Canadian primary care, and this profile follows that work rather than inventing alongside it.

CA-eReC (pan-Canadian eReferral-eConsult, Canada Health Infoway) is the national specification. Its ServiceRequest fixes intent = proposal, requires requester and authoredOn, and binds status to the base FHIR request-status set.

The Ontario eReferral / eConsult IG (ca-on-eReferral-profile-ServiceRequest) derives from CA-eReC and adds Ontario's routing and delegation extensions. This IG carries ca.on.erec.r4 as a pinned dependency.

NexusCoreReferral aligns with both on the constraints that matter for interoperability: intent = proposal, requester required, authoredOn required, status required-bound.

There are two deliberate divergences, both recorded on the profile itself.

performer is optional here

CA-eReC makes performer 1..*. That profile governs electronic referral messaging, where a destination is definitionally known: you cannot send a message with no recipient.

Nexus also records referrals that were never sent electronically. A dictated letter to a named consultant, or a referral written before its target has been chosen, is a real referral that belongs in the chart. Requiring performer would make those unrecordable, so the profile keeps it 0..* and asks that it be populated whenever the destination is known.

Systems exchanging referrals over Ontario eReferral should treat performer as required, because the Ontario profile they are also claiming does.

category binds a different value set

CA-eReC binds both category and code to Infoway's InterventionCodeSubsetCare. This IG does not adopt that binding, for two reasons.

The first is semantic. InterventionCodeSubsetCare represents "the care procedures performed by a Provider" -- an intervention taxonomy. That describes what code means. It does not describe what category carries on a referral, which is the receiving service.

The second is decisive: Infoway retired that value set in April 2026, together with the Primary Health Care EMR Minimum Data Set it belonged to, and marked it "not recommended for continued use".

So category binds NexusReferralServiceType, which mirrors Infoway's active, purpose-built ReferralServiceCategoryCode -- the union of SNOMED CT healthcare services and provider specialties, over the Canadian Edition reference set 379431000087101. code is left with the base R4 binding until Infoway publishes a replacement for the retired set.

It is a service type, not a specialty

The natural name for this concept is "specialty", and a specialty-only value set will not work. Several destinations a primary-care referral routinely targets exist in SNOMED CT only as service concepts, with no specialty concept at all: Sports medicine, Sleep medicine, Spinal surgery and Clinical neurophysiology among them.

Infoway's set is a union of services and specialties precisely because the domain is. Implementers building a referral destination picker should expect both kinds of concept in it and should not filter to the specialty hierarchy.

What Ocean sends

Ocean's eReferral integration is the largest source of referrals Nexus receives. Ocean declares ca-on-eReferral-profile-ServiceRequest and sends, in outline:

{
  "resourceType": "ServiceRequest",
  "meta": { "profile": ["http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-ServiceRequest|1.0.1"] },
  "status": "active",
  "intent": "proposal",
  "category": [{ "coding": [{ "system": "http://snomed.info/sct",
                              "code": "17561000", "display": "CARDIOLOGY" }] }],
  "priority": "routine",
  "subject":   { "reference": "urn:uuid:..." },
  "requester": { "reference": "urn:uuid:..." },
  "performer": [{ "reference": "urn:uuid:...", "identifier": { "system": "...id-referral-target-external-service", "value": "..." } }],
  "authoredOn": "2025-03-07T16:14:13-05:00"
}

Two things about this payload drive design decisions in the profile.

There is no code element

Ocean carries the routing information in category and sends no code at all. This is why code is 0..1 on the referral profile where it is 1..1 on the order profile. A required code would make the referrals Nexus actually receives non-conformant.

The legibility floor the order profile gets from code.text 1..1 is preserved conditionally instead: the referral-code-has-text invariant requires code.text when code is present. Nexus-authored referrals should populate both, from the reason for referral, so the receiving clinician can see what is being asked without opening the letter.

The category code is an occupation concept

Ocean sends 17561000. In SNOMED CT that concept is Cardiologist (occupation) -- a person, not a service or a specialty. The specialty concept for cardiology is 394579002 |Cardiology (qualifier value)|, and the two sit in different hierarchies. They are not synonyms, and asserting an equivalence between them would be wrong.

This is why category has an extensible binding rather than a required one: 17561000 is not a member of NexusReferralServiceType, and a required binding would reject live Ontario traffic.

The pattern to follow on receipt:

  1. Preserve the raw coding exactly as received. It is the evidence of what the sending system meant, and normalising it away destroys the only record of that.
  2. Add the Nexus coding alongside it, in the same CodeableConcept. Both codings describe the same destination.
  3. Do not rewrite or drop the original.
"category": [{
  "coding": [
    { "system": "http://snomed.info/sct", "code": "17561000",  "display": "Cardiologist" },
    { "system": "http://snomed.info/sct", "code": "394579002", "display": "Cardiology" }
  ],
  "text": "Cardiology"
}]

A read path that classifies referrals by destination should recognise both codings. Treat the inbound-to-Nexus mapping as a source normalisation, not a terminology equivalence: it records how one sending system's vocabulary lines up with ours, and it is not a claim about SNOMED CT.

Coding referral destinations

Referral destinations are routing information. A referral coded to the wrong destination reaches the wrong service, so destination codes deserve the same care as a medication code.

  • Validate every code against a terminology server before shipping it, with the display term, not just the code. $validate-code with system, code and display catches the failure mode that matters: a code that exists, and resolves to a different specialty than the label next to it claims. A code-only check passes on exactly the cases that hurt.
  • Do not assemble destination catalogues by hand or by pattern-matching code shapes. SNOMED specialty concepts sit in narrow numeric bands, which makes a wrong code in the right band look plausible on inspection.
  • Expect service concepts alongside specialty concepts (see the note above), and do not filter them out.
  • Where a destination has no usable code, leave it uncoded and carry the text rather than mapping it to an approximate neighbour. An approximate destination routes the patient approximately.

    referral-category-coded reports this as a warning, not an error, and that is deliberate: a referral carrying only text is conformant. It is the same reasoning that made the category binding extensible rather than required. A rule that makes the referrals we actually receive non-conformant is enforcing our preferences rather than the specification. The warning is still worth acting on where a code exists, because a referral whose destination is only free text cannot be routed, counted, or matched to a reply.