Referral intake

A referral is recorded from Referrals in the Rehab sidebar. Three fields are required - first name, last name and date of birth - and everything else is optional, including the discipline.

That is deliberate. A referral arrives in the middle of a busy morning, and a form that demands a clinical decision nobody has made yet gets worked around rather than used. The discipline is asked for later, at the moment somebody actually decides it.

Recording a referral does not create a patient record. Until somebody accepts it, a referral is a request from an outside clinician and nothing more - which matters, because a declined referral must not leave a patient record behind for a person your organisation never treated.

Referrals are recorded by your staff, or sent across from ArkCloud Access where your organisation uses it. ArkCloud does not receive referrals automatically from fax, HL7 v2 or Direct messaging.

A faxed referral is typed in as a referral. Scan the faxed pages to a PDF and upload them under Overview → Outside records, document type Referral, arrived “Fax or paper, scanned”, so the clinician can read the original. ArkCloud does not read the text of a scanned page - see documents and scanning.

A FHIR R4 referral exchange with a referring EHR is built: an administrator configures the partner connection under Rehab settings → Integrations → Referral exchange, and referrals that arrive, need review or were refused appear on the Electronic referrals screen, which also sends status updates back to the referrer. Nothing arrives until your organisation sets up a connection with the referring organisation.

Opening a referral also shows a missing-information checklist and, where switched on, a quote-backed AI summary of the reason for referral - see referral summary. Neither changes the referral.

An organisation that also runs ArkCloud Access can send a referral from the Access queue straight into this one; only an Access administrator can send it. The clinical referral that arrives is an ordinary referral in every respect — same triage, same conversion, same encryption — and is indistinguishable here from one recorded directly in Rehab.

Nothing is re-typed. The referrer, the referring organisation, the reason and the urgency carry across from the intake record. The coordinator in Access confirms only the two things an intake record cannot carry on its own: how the patient's name splits into first and last, and the date of birth.

Once sent, the Access record stops being the authority on what happens next. Its status is read from the referral you are looking at here, so a decision you make in Rehab — triaged, declined, accepted into care — is what the front desk sees. There is no second copy to keep in step.

The origin is recorded in the audit trail against both records, so “where did this referral come from” is answerable after the fact.

Triage records what the referral is for - discipline, setting and urgency - along with any notes, and who it is waiting on. Saving triage detail does not decide the outcome; accepting and declining are separate, explicit actions.

The statuses are Received, Triaged, Accepted, Declined, Withdrawn and In care. A referral can be accepted into care from Received, Triaged or Accepted - the Accepted status records the decision and does not itself create anything.

Urgent referrals sort to the top of the worklist ahead of routine ones, then oldest first, so the referral that has been waiting longest in the more urgent band is always the first thing on the screen.

Accepting a referral does three things in a single operation: it creates or links the patient record, admits that patient to Rehab, and opens the episode of care. The patient's name and date of birth come from the referral - nobody types them again.

You are asked for one of two things first. If this person is already known to your organisation, search for them and choose the existing record. If they are new, supply the medical record number to create them under. A discipline must also be set by this point - it is optional when the referral is recorded, and required when care starts.

Who issues the medical record number is an organisation setting. By default (External) the number comes from your own record system and must be typed; ArkCloud will not invent one, because an invented number cannot be reconciled with your system and collides the first time the real one arrives. An administrator can instead have ArkCloud assign numbers from a per-organisation counter, under Rehab → Outpatient → Patient identifiers; a number typed by hand is still accepted under that setting.

ArkCloud never decides that two people are the same person. A referral is attached to an existing patient by exact medical record number, or by a record a person searched for and chose. Nothing treats a matching name and date of birth as a match - that inference merges two people's clinical records, and no automatic rule makes it.

A medical record number that belongs to somebody else is refused. An MRN is typed by hand, and one wrong digit points at a real patient. So when the number you enter already exists, ArkCloud checks that the surname and date of birth on that record match the referral, and refuses if they do not - rather than quietly opening an episode of care on a stranger's chart.

If the record really is the right one and the demographics differ - somebody changed their name, or the referral has it wrong - search for the patient and choose them directly. That path is deliberate: you are looking at the chart when you decide.

All three records are written in one database transaction. If any part fails, nothing is created and the referral is left exactly as it was - there is no state in which a referral says care started but no episode exists.

It is safe. A double-click, a retried request, or two coordinators acting at the same moment all produce one patient and one episode. The second attempt finds the work already done and returns the same episode rather than opening a second course of care.

This matters more than it sounds. Two episodes for one course of care split that patient's authorization, their notes and their claims across two records, and the problem usually surfaces only when the second claim is denied.

A referral that this organisation does not take on is declined. One that ends because the referrer or the patient withdrew it is withdrawn. Both require a reason.

The two are kept apart on purpose: only one of them is a decision your practice made and has to answer for, and counting a patient who never called back against your acceptance rate would misreport both numbers.

A referral closed in error can be reopened. It returns to Received and keeps its original arrival date, because every waiting-time and conversion figure is measured from when the referral actually arrived.

No status can be set to “In care”. That state exists only as the result of a patient record and an episode of care actually being created, and the database enforces it independently of the application: a referral row claiming care started without both records is rejected by a constraint, not by a code path.

This is the difference between a status that records something and a status somebody typed. A referral list where a coordinator can mark a row “scheduled” with no appointment behind it cannot be reported on, and the reports built from it are worse than none.

If the referrer supplied an ICD-10 code, it is recorded and shown as the referrer's code. ArkCloud checks its format and nothing else.

It is not validated as clinically correct for this patient, it is not copied onto the episode as a diagnosis, and it is never used to code a claim. Code selection is a licensed billing judgement that varies by payer, programme and jurisdiction, and nothing in ArkCloud derives a procedure code from a referral.

The worklist carries four figures: referrals open, referrals that became an episode of care, the conversion rate, and the median days from referral to the start of care.

The conversion rate excludes referrals still open. A practice that received fifty referrals this morning has not failed to convert them, and counting them would show a collapsing rate every time business was good. Where nothing has yet reached a decision the figure is shown as a dash rather than as zero - “no data” and “we convert nobody” are different facts.

All four are computed from the referral records themselves at the moment you look, not from a separate reporting table, so they cannot drift from the underlying data.

A referral names an identified person before they are your patient. The name, date of birth, any medical record number, the referrer's stated reason, triage notes and the outcome reason are encrypted at rest - the database stores only ciphertext for those fields.

The referring provider and organisation are not encrypted. They name a clinician and a practice rather than the patient, and they stay readable so that referral-source reporting is possible at all.

Every referral action is recorded in the audit trail with identifiers only. No patient name, date of birth, medical record number or clinical reason is written to an audit record.

Viewing, recording and triaging referrals, and accepting them into care, are open to every role Rehab admits - Agent, Supervisor and Admin - so front-desk staff can do all of it. Client-portal and payer identities have no access to referrals, as they have no access to Rehab at all.

Today every role Rehab admits - agent, supervisor and administrator - may record, triage and accept referrals. Accepting into care is checked separately in the code so that it can be narrowed later, but there is no per-organisation setting yet that separates intake staff from clinicians.