Every patient starts as somebody else's paperwork
An outpatient rehabilitation practice does not find its patients. They are sent.
A physician decides a patient needs physical therapy. A surgeon discharges someone with an order for post-operative rehab. A paediatrician refers a child for speech and language work. That decision leaves the referring practice as a fax, a portal message, a scanned PDF, or a phone call, and it lands on a desk at the receiving clinic.
That moment is the front door of the entire business. Everything downstream - the evaluation, the plan of care, the authorization, the visits, the notes, the claims - exists because a referral arrived and somebody acted on it.
It is also, in a remarkable number of rehabilitation systems, the part that is barely software at all.
The dead-end referral
Here is the pattern we keep finding, including in our own product until recently.
There is a referral list. You can add a referral to it. It captures the patient's name as a line of text, who sent it, and a status you can set by hand: New, In review, Accepted, Scheduled.
And then it stops.
The referral has no connection to anything. The name on it is a string, not a patient. Accepting it does not create a patient record. Marking it "Scheduled" does not schedule anything - it is a word a coordinator typed, and nothing behind the screen checks whether an appointment exists. To actually start care, someone opens a second screen and types the patient's name, date of birth and demographics again to create the patient. Then a third screen, to open the episode of care.
Three screens. The same person's details entered two or three times. And at the end of it, no link back: nothing in the system knows that this episode of care came from that referral.
What that actually costs
It is tempting to file this under "minor inefficiency". It is not one, for four separate reasons.
Re-typing is where wrong records come from. Every re-entry of a name and a date of birth is an opportunity to transpose two digits. A patient created with the wrong date of birth fails eligibility checks that would otherwise have passed, and the denial arrives weeks later looking like a payer problem rather than a typing one.
Duplicate patients split clinical histories. When a coordinator cannot easily tell that the person on this referral is the same person the practice treated eighteen months ago, they create a second record. Now that patient has two charts. Their previous course of care, their prior authorizations and their outcome history sit under an identity nobody will think to look at.
The status lies. A referral marked "Scheduled" with no appointment behind it is worse than an unmarked one, because somebody will trust it. Reports built on hand-set statuses describe the data entry, not the practice.
And the single most important number in the business becomes uncomputable. Ask any outpatient rehab operator what they watch, and referral conversion is near the top: of the referrals we received, how many became patients we actually treated? If referrals and episodes of care are not linked, that question has no answer. Not a hard one - no answer at all. The best a disconnected system can do is count rows in two tables that have nothing to do with each other.
That last one is why this is a strategic problem rather than a usability one. A practice that cannot measure referral conversion cannot tell whether a referral source is drying up, whether urgent referrals are waiting too long, or whether the reason the schedule is thin this month is fewer referrals or worse follow-up. Those are the decisions a clinic director makes with the information in front of them, and most of them are flying without it.
What we built
ArkCloud Rehab now treats the referral as the first step of the clinical workflow rather than as a note beside it.
A referral is recorded with three required fields: first name, last name, date of birth. Everything else - the referrer, the reason, the discipline, the urgency - is optional.
That was a deliberate decision and it is worth explaining, because the instinct is the opposite. A referral arrives in the middle of a busy morning. If logging it demands a clinical decision nobody has made yet, the referral does not get logged - it goes in a pile, and the pile is the system we are trying to replace. So the form asks for the minimum that identifies a person, and asks for the clinical decisions at the point where somebody is actually making them.
From there a coordinator triages it: what discipline, what setting, how urgent, who is it waiting on. Urgent referrals sort above routine ones, then oldest first, so the thing that has been waiting longest in the more urgent band is always at the top of the screen.
And then the part that matters. Accepting a referral into care does three things in one operation:
- creates the patient record, or links to the existing one
- admits that patient to Rehab
- opens the episode of care
The patient's name and date of birth come from the referral. Nobody types them again. The clinician lands on the episode, which is where the evaluation, the plan of care, the authorization and the visits all hang off - the workflow that was already there, now reachable from the door rather than from a blank form.
The decisions underneath
A workflow like this is mostly made of refusals. These are the ones we think are load-bearing.
No status can be set to "in care". That state exists only as the result of a patient record and an episode actually being created. It is enforced in the database with a constraint, not only in application code, so a referral row claiming that care started without both records is rejected outright. This is the direct fix for the status that lies: the claim cannot be made unless the thing it claims is true.
We never decide that two people are the same person. A referral attaches to an existing patient by exact medical record number, or by a record a human searched for and chose from a list they can see. A matching name and date of birth is not treated as a match. Automatic identity matching merges two people's clinical records when it is wrong, and no rule gets to make that call silently.
We do not generate medical record numbers. If the patient is new, the practice supplies the number. An invented identifier looks authoritative, cannot be reconciled with the organisation's own record system, and collides the first time the real one arrives.
Accepting the same referral twice is safe. A double-click, a retried request, or two coordinators acting at the same moment produce one patient and one episode. The second attempt finds the work already done and returns the same episode. This is not defensive polish: two episodes for one course of care split that patient's authorization, notes and claims across two records, and the problem usually surfaces only when the second claim is denied.
Everything happens in one transaction. If any part fails, nothing is created and the referral is left exactly as it was. There is no state in which the system says care started but no episode exists.
Declining and withdrawing are different outcomes. A referral this practice chose not to take on is declined. One that ended because the referrer or the patient withdrew it is withdrawn. Both require a reason. Only one of them is a decision the practice made and has to answer for, and counting a patient who never called back against your acceptance rate misreports both figures.
What the system still does not do
Being specific about this is more useful than a feature list.
Referrals do not arrive on their own. ArkCloud does not currently receive referrals automatically from inbound fax, HL7, Direct messaging or a referring practice's EHR. A referral is recorded by a member of staff. That is a real gap and we are not going to describe it as anything else.
We do not interpret the referral's clinical content. If the referrer supplied an ICD-10 code, we record it and show it as the referrer's code. We check its format and nothing else. It is not validated as clinically correct, it is not copied onto the episode as a diagnosis, and it is never used to code a claim. Procedure and diagnosis selection is a licensed billing judgement that varies by payer, programme and jurisdiction, and nothing in ArkCloud derives a billing code from a referral.
Eligibility and benefits are not checked at intake. Recording a referral tells you somebody was referred. It does not tell you whether they are covered.
On measuring it honestly
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.
Two details in how they are computed are worth naming, because they are the difference between a number an operator can act on and a number they learn to ignore.
The conversion rate excludes referrals that are still open. A practice that received fifty referrals this morning has not failed to convert them. Including them in the denominator would show a collapsing conversion rate every time business was good, which is the fastest way to teach somebody that a dashboard is not worth reading.
And where nothing has yet reached a decision, the figure shows a dash rather than zero. "No data" and "we convert nobody" are different facts, and a zero on a screen reads as the second one to the person whose work is being measured.
All four figures are computed from the referral records themselves at the moment you look, rather than from a separate reporting table. There is no counter to drift out of step with reality.
Privacy, and where the line sits
A referral names an identified person before they are your patient, which makes it an unusual object: it is protected health information about somebody your organisation may never treat.
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 holds ciphertext for those fields.
The referring provider and organisation are not encrypted, and that is a decision rather than an oversight. They name a clinician and a practice rather than the patient - the same class of data as a payer name - and they have to stay readable for referral-source reporting to be possible at all. Encrypting them would mean no practice could ever ask which physicians refer to them without decrypting every row in the table.
Referrals are isolated per organisation at the database level, not only in application code: a query that arrives without an established organisation context returns nothing rather than everything. Every referral action is written to the audit trail with identifiers only - no name, no date of birth, no medical record number, no clinical reason reaches an audit record.
Why this was the thing to build
We had the rest of it. Appointment to encounter to signed note to billable service to charge to authorization draw-down to claim - that chain existed and was tested end to end.
What it could not answer was how the patient got there.
A connected platform that starts halfway through the workflow is not connected; it just has a shorter seam. The referral is where the patient enters the organisation, where the first identity decision is made, and where the first number the business is judged on begins. Leaving it as a note beside the product meant every customer's day still started in a pile of paper and ended with the same details typed three times.
It is the least glamorous part of the workflow. It is also the door.
ArkCloud Rehab is generally available. Referral intake is documented at [/docs/rehab/referrals](/docs/rehab/referrals).
Related reading: what patients expect when they pay, and RCM trends for 2026.
