Referral origination starts with a clinical question, not a booking request
A good referral explains what problem needs solving, why the receiving service is needed, and what information or action is expected in return.
This distinction matters architecturally. If the order only says "please book imaging" or "specialist review requested," the receiving organization has to recover missing intent by phone calls, manual review, and unsafe guesswork.
Who touches the referral before fulfillment begins
Loading diagram...
ACR Appropriateness Criteria overview
ACR overview of evidence-based imaging appropriateness criteria and the decision framework used before advanced imaging is ordered.
Read the ACR overviewServiceRequest - FHIR v4.0.1
FHIR definition showing that a referral is a request for service and may support transfer of care or specialist consultation.
Read the FHIR workflow definitionPersona handoffs determine whether the referral stays clinically usable
Closed-loop referral design is mostly handoff design. Each role needs a clean boundary: who provides clinical justification, who validates completeness, who decides urgency, who owns booking, who performs the service, and who confirms closure back to the requester.
Common personas and their architectural responsibilities
| Role | Primary responsibility | Failure if weak |
|---|---|---|
| Referrer | Provides clinical need, reason, urgency, and destination intent. | Receiving team cannot judge appropriateness or priority. |
| Booking or intake coordinator | Validates data, routes referrals, and manages patient contact. | Demand sits in limbo or is booked against the wrong service. |
| Specialist or radiologist | Confirms urgency, modality, protocol, or acceptance conditions. | Unsafe or low-value studies proceed without clinical review. |
| Technologist or servicing team | Executes the service with the correct patient and exam context. | Wrong-patient, wrong-service, or incomplete execution events occur. |
A referral can be complete on paper and still fail operationally
If responsibility for a state change is ambiguous, status updates become fiction. Teams then see a referral as "received" or "booked" without anyone being accountable for what that status really means.
IHE Radiology Scheduled Workflow profile
Reference workflow for actor responsibilities across order placer, order filler, acquisition modalities, and reporting steps.
Review the workflow actorsContained HISO 10011.1 referral business-process standard
Contained legacy referral business-process standard that is still useful for studying handoff responsibility and explicit state ownership across organizations.
Read HISO 10011.1 (contained standard)Requester identity and intended destination need to survive the first handoff
Referral origination is not only about describing the clinical problem. The outbound request also needs an accountable requester, a clear authored moment, and an intended destination or service type that later teams can trust when they validate or redirect the work.
This matters whenever requests are entered by delegated staff, sent through a referral hub, or redirected between services. If the receiving organization has to reconstruct who requested the service or which team was supposed to receive it, the first clarification loop already loses operational truth.
Origination-to-acceptance handoff
Loading diagram...
ServiceRequest - FHIR v4.0.1
FHIR request resource definition covering requester, performer, authoredOn, reason, and other fields that should survive the origination handoff.
Review request accountability fieldsContained HISO 10011.3 referral implementation guide
Contained legacy implementation guide that still illustrates how referral business events and responsibility boundaries can stay explicit as requests move between organizations.
Read HISO 10011.3 (contained guide)Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.