AI for Patient Intake: From Referral to Registered, Without the Backlog

A referral arrives as a fax at four in the afternoon. Someone keys the demographics, checks the insurance, spots that the plan needs authorisation, chases the missing imaging report, and books the patient three weeks later than the referrer expected. Multiply that by your front desk volume and the queue never empties.

Almost all of that work is administrative. It reads information from one place, checks it against known rules, and writes the result into another. That is the shape of work AI agents handle well, and what Adopt AI Partners builds agents for. This page is about that administrative half of intake, and only that half.

What we mean by intake, and what we do not

In scope: getting a referral into your system, capturing demographics and insurance, verifying eligibility and benefits, preparing prior authorisation packets, reconciling registration forms, chasing missing information, coordinating scheduling, sending pre visit instructions, and writing a structured record into the clinical system for a person to accept.

Out of scope: anything that assesses a patient's condition. No symptom triage. No urgency scoring from clinical presentation. No advice about what symptoms mean. Software that does those things is making a clinical claim, and in most jurisdictions that is a regulated medical device question with its own evidence and approval requirements. A legitimate field, but not this one, and mixing the two inside one system is how organisations build a compliance problem without noticing.

Where a referral contains something that looks clinically urgent, the agent does one thing: it stops and routes it to a person under your protocol. Escalating is not triage. Deciding is.

Referral intake from fax, portal and post

Referrals arrive in every format your referrers use: a fax that has been printed, signed, scanned and faxed again, a portal submission with half the fields blank, a posted letter, and a structured electronic referral if you are lucky.

The agent takes the first read on all of them. It extracts the patient identifiers, the referring practice, the requested service, the stated reason as written, and the attachments, then checks the package against your acceptance criteria: is the referral in scope, is the required documentation attached, is there enough identifying information to match a patient.

Complete packages are registered and queued with a structured summary on top, so the reviewer reads a paragraph rather than fourteen pages. Incomplete ones generate a drafted request back to the referrer. Ambiguous ones go to a human without a guess attached.

Demographics, insurance and eligibility verification

Demographic capture is transcription with high stakes. A digit wrong in a date of birth creates a duplicate record that someone unpicks months later. The agent extracts the fields, normalises them to your formats, and searches for an existing patient before creating anything new, surfacing near matches for a person to confirm rather than merging alone.

Insurance is the same problem with a live system behind it. The agent reads the plan details, checks them against the payer through your existing eligibility channel, and records what came back: active or not, the plan and product, effective dates, copay and deductible position, network status.

Clean responses are attached to the case and intake continues. Where the payer returns nothing useful, or the plan has lapsed, or the name does not match, that becomes a flagged item with the discrepancy stated, for a person to resolve with the patient.

Prior authorisation preparation

Authorisation work is mostly assembly. Where the service and the plan require one, the agent pulls the payer's published criteria and gathers the evidence they call for from what you already hold: diagnoses, prior treatments, imaging, correspondence.

It builds the packet, cites where each piece came from, and puts it in your authorisation queue. Where evidence is missing, it says what is missing and who can supply it, rather than letting the request bounce back later. A person submits, and a person owns any conversation with the payer. The agent's contribution is that nobody starts from an empty form and nothing sits pending until somebody remembers it.

Registration forms and reconciliation against the record

Registration forms repeat what you already know and contradict the record often enough that nobody trusts either version. An intake agent reconciles them properly. It pre populates what you hold so the patient confirms rather than retypes, ingests what comes back, and compares field by field. Matching fields pass. Differences are listed explicitly: address changed, a new secondary insurance, a different emergency contact. Each is a proposed update with both values visible, and a person accepts or rejects it. The agent does not silently overwrite a clinical field.

Chasing missing information and coordinating the appointment

Most intake delay is not work, it is waiting: the outstanding imaging report, the unreturned insurance card photograph, the referrer who has not answered, the patient who has not completed their forms.

An agent earns its place here, because the job is memory and persistence. It tracks what is outstanding, confirms the item is genuinely still missing, and acts inside limits you set: a reminder to an internal queue, a drafted chaser to the referring practice, a patient message from your approved templates. Every attempt is logged, and anything still stuck after a set number of attempts escalates to a named owner rather than looping forever.

Once a case is complete and authorised, booking is a constraint problem: the right clinic and resource, the preparation window, the patient's availability, your rules about which slots that service may occupy. The agent proposes options and, within your limits, books the ones that clearly fit, then delivers the pre visit instructions for that appointment type from your approved library. It does not compose medical guidance, and a patient who replies asking what their symptoms mean is routed to a person.

The handoff into the clinical record

The write is where discipline shows. The agent produces a structured intake summary with the source of every field, the coverage detail and its verification timestamp, the authorisation status, the outstanding items, and the referral document linked rather than paraphrased.

That package goes into the clinical record through your existing interfaces, as a pending item where your workflow requires acceptance, using a service account with the narrowest permissions the job needs. When someone asks in six months where a value came from, the answer is in the record.

Consent, PHI and access control

The agents run inside your boundary: your tenancy or data centre, your network controls, your identity and access management. Patient data is not shipped into a third party's multi tenant product and is not used to train anybody's models. Each agent authenticates as its own service account with minimum necessary access, so an intake agent cannot read charts it has no business reading.

Every read and write is logged with the identity, the record, the action and the timestamp, so you can answer what the agent saw and did for any patient on any day. Retention follows your policy. Consent state is a hard gate rather than a note: communication preferences, permission to leave messages, permission to contact a representative, and any restriction on disclosure all constrain what the agent may send and to whom. If consent for a channel is absent or unclear, the agent does not use that channel.

Why a person confirms identity and insurance

Two checkpoints stay human even when everything else runs itself.

Identity, because a mismatch is not a data quality issue, it is a patient safety issue. Attaching a referral to the wrong person causes harm that takes a long time to find. The agent narrows the candidates and shows its evidence; a person confirms.

Insurance, because the financial consequence lands on the patient. A verification that reads active when the plan lapsed produces a bill nobody agreed to. Before anything binding, a person confirms coverage. The agent's job is to make that take fifteen seconds instead of fifteen minutes.

How you evaluate before you trust it

Trust is earned against a measured baseline, not asserted in a demo.

Build an evaluation set from your own historical intake: several hundred real referrals and registrations spanning the good, the messy and the genuinely odd, with the correct outcome established by your staff. Run the agent against it in shadow mode, where output goes nowhere, and compare field by field.

Measure separately. Extraction accuracy per field, because a system that is right overall can still be wrong about dates of birth. Eligibility agreement against what your staff determined. False confidence rate, how often it asserted something wrong without flagging uncertainty, which should govern how much authority it gets. Then the operational numbers: minutes per referral, days from referral to appointment booked, rework rate.

Widen authority one decision at a time: draft only first, then autonomous action on the narrow class of cases where accuracy is proven and failure is cheap and visible. Keep the shadow comparison running after go live, because payer rules and referrer habits change.

Where AI fails here

Agents fail on bad source data. A fax of a fax with a smudged date of birth will be read confidently and wrongly, which is why identity confirmation is human and why extraction confidence must be surfaced rather than hidden. They fail on the genuinely novel case, the plan structure nobody has seen or the referral that fits no service, where a forced guess is worse than an escalation. They fail when payer behaviour changes without notice, which is why eligibility results are timestamped and rechecked. Language models can state things fluently that are not so, which is why nothing binding goes out without a person. And no agent repairs a broken process: if your pathway loses cases today, automating it loses them faster.

The last failure is scope creep, and it is the one to guard hardest. A system built for administrative intake will, if you let it, be asked to say something about how sick the patient sounds. Do not let it. That is a different product with a different regulatory path, and the value of an intake agent comes from doing the administrative work completely and stopping at the line.

Where to start

Pick one referral pathway: one service, one set of payers, one team who feels the pain daily. Measure the baseline first, run in draft only mode until the output survives contact with the people doing the work now, then widen slowly. If you would like a grounded view of whether an agent can carry part of your intake, describe that pathway to Adopt AI Partners and we will tell you what is worth building and what is not.