Registering and scheduling a referred patient without any agent touching a clinical decision
Intake is where a patient becomes a record, and most of what delays it is administrative: a referral arrives missing a detail, the identity is ambiguous, coverage has to be confirmed, and a slot has to be found that fits what the referrer asked for. None of that is a clinical decision, and the design is built so that none of it quietly becomes one. Modeled as an orchestrated process, the administrative work runs while the instance stays open, and a person is reached when identity, coverage or availability is genuinely unresolved. The clinical content of the referral travels with the instance and is read by the clinician it was written for.
A reference architecture: how RoboAgentix would model this process on UiPath. It is not a description of a delivered project, and no client, result or metric is implied.
What starts it
A referral arrives — from a referring practice, a portal, a health information exchange feed, a monitored mailbox, or a patient completing a registration form.
Why it is orchestrated rather than scripted
- A referral waits on a coverage service, on a clinic's availability, and often on the referring source to send back something missing — the instance has to stay alive across all of it.
- The line between an administrative check and a clinical decision has to be enforced in one place, as a rule people can read, rather than inside each robot's branching.
- Which record a patient was matched to, and on what coverage finding they were booked, are questions asked long after the appointment has happened.
How it runs on UiPath Maestro
The process is defined in BPMN and Maestro runs it across agents, robots and people, holding its state for as long as the work takes — including while it waits on an approver.
Step by step
- 01
Referral receivedSystem
From a referring practice, a portal, a health information exchange feed, a monitored mailbox, or a patient's own registration form.
- 02
Read the administrative detailAgent
Patient identifiers, contact details, the referring source, the requested service and any stated window are classified and extracted, each field carrying a confidence score. The clinical narrative is carried forward untouched.
- 03
Resolve identity and coverageAgent
The extracted patient is matched against the master patient index, and scheme membership and the administrative coverage rules for the requested service are checked, citing the rule applied.
- 04
Clear to schedule?Maestro
The orchestrator routes on whether identity resolved to one record, whether the coverage check passed, and whether a slot exists inside the window the referral states.
- 05
Intake clerk reviewPerson
Anything unresolved reaches a clerk with the referral, the candidate patient records, the coverage finding and the availability that was searched.
- 06
Register and bookRobot
A robot writes the administrative record, books the confirmed slot, and returns the appointment reference to the referring source.
- 07
Registered and scheduledSystem
The appointment stands, the referring source holds the reference, and the identity match, the coverage finding and any human decision are written to the audit record.
What each agent is allowed to decide
An agent is only useful in a governed process if its authority is written down. Each one below has a defined input, a decision it may make on its own, and the condition that obliges it to hand over.
Referral Intake Agent
Turns a referral into the administrative fields a registration needs, and nothing more.
Reads
- The referral and its attachments
- The clinic's required-field list for that service
- The service catalog as the clinic publishes it
Decides on its own
Must escalate when
Identity and Coverage Agent
Decides whether this is an existing patient, and whether the scheme covers the requested service on administrative grounds.
Reads
- The master patient index
- Scheme membership and coverage records
- The scheme's administrative rules, indexed for retrieval
- Prior referrals recorded against the same patient
Decides on its own
Must escalate when
Scheduling Agent
Proposes a slot that fits the referral as it was written.
Reads
- Published clinic availability and the booking rules for that service
- The window and priority written on the referral
- Patient contact preferences and stated access needs
Decides on its own
Must escalate when
What the robots do
Deterministic steps stay with robots — the same action every time, including in systems that never exposed a usable API.
Registration robot
Creates or updates the patient's administrative record and attaches the referral to it.
Runs in
Booking robot
Books the confirmed slot, issues the appointment notice, and writes the reference back to the referring source.
Runs in
Clear to schedule?
Identity resolved to exactly one record, coverage active for the service as written, every field the clinic requires present and above its threshold, and a slot available inside the window the referral states.
- Passes
- Registered and booked without a person touching it.
- Does not pass
- Held for the clerk, or returned to the referring source, with the process kept open until it comes back.
Modeled as a decision table, so the threshold can be changed by the people who own the policy without redeploying an automation.
The human step
Who
What they see
What they decide
People are in this process because judgment or authority belongs to them — not as a fallback for a step that failed.
What this design deliberately does not do
An automation is only trustworthy if its limits are written down as plainly as its capabilities.
- It does not read the clinical content of a referral for meaning. Clinical narrative is carried through to the receiving clinician and is not summarized, scored or acted on by any agent.
- It does not triage. Urgency is whatever the referring clinician wrote on the referral; nothing in the process infers it, raises it or lowers it.
- It does not decide medical necessity or whether the requested service is appropriate. Where a scheme requires that judgment, the instance is routed to the clinical reviewer the scheme names.
- It does not reject a referral or deny coverage on its own. A failed check produces a registration held for a person, never a patient turned away by the process.
Failure has a defined path
Systems go down, confidence drops, approvers go on leave. Each of these is a modeled branch rather than a stuck instance.
- The coverage or eligibility service is unreachable when the check is due.
- The instance stays open and the check is retried on the schedule Orchestrator holds. Registration and booking do not proceed on an assumed result; if the service is still unreachable as the referral's stated window approaches, the instance is raised to the clerk queue as an unverified registration for a person to decide.
- A required field is extracted below its confidence threshold, or the identity match returns more than one candidate record.
- No record is created and no record is merged. The instance goes to a clerk with the candidates side by side and the fields the agent was unsure of, and the clerk's choice is stored against the instance as the resolution.
- The clerk or clinical reviewer the task was assigned to never acts on it.
- The task ages in Action Center and is reassigned by the rule for that clinic — to the queue rather than to another individual. If the referral states a window, the instance is raised before that window closes rather than after, and the referring source is notified that the referral is still unactioned.
- No slot exists inside the window the referral states.
- The process does not book outside the window and does not defer on its own. It routes to the clinic's scheduler with the referral, the stated window and the availability it searched, and holds until a person books, adds capacity, or returns the referral to its source with a reason.
Data, rollout, and what to watch
Data it touches
- The process touches patient identifiers, contact details, scheme membership and whatever the referring clinician wrote. Which of those fields each component may read is set per component: the registration robot's credentials reach demographic and referral fields only, and no clinical record is in its scope.
- Clinical narrative is carried as an attachment on the instance and handed to the receiving clinical team. It is not placed in an agent's prompt, not indexed for retrieval, and not copied into the process's own variables.
- Context Grounding indexes the organization's own administrative material — scheme rules, clinic booking rules, the published service catalog. Patient records are not part of that index.
- An Action Center task shows only the fields the decision in front of that person requires, and where the process runs, where its state and audit records are held, and how long they are kept follow the residency and retention rules the organization is bound by.
How it goes live
- 01
Shadow
The process runs beside the existing intake desk on real referrals and writes nothing. Agent output is recorded next to what the clerks actually did, field by field, and every identity match is compared against the record the clerk chose. The gate to the next phase is agreement on identity and coverage across the referral types and sources the clinic really receives, including the malformed ones — not across a clean sample.
- 02
Supervised
Every instance produces a proposed registration and a proposed slot, and every one is confirmed by a clerk in Action Center before a robot writes anything. What clerks change is the measurement. The gate is set per referral type and per source: a type moves on when clerks stop correcting it, and the types that keep being corrected stay supervised.
- 03
Unattended with exceptions
Referral types that cleared the gate register and book without a person. Everything else still reaches one — the types still supervised, anything below confidence, an unresolved identity, a failed coverage check, and every case the design routes to a clinician. The unattended set is an explicit list, and any type can be put back under supervision without a redeploy.
Signals worth watching
- The share of instances that reach a person, and whether it is drifting for a particular referral source or service.
- How often a clerk changes the identity match that was proposed — the signal worth watching most closely, because a wrong merge is harder to undo than a delay.
- Registrations and bookings that are corrected downstream: a record merged later, an appointment amended, a patient contacted again — the errors the gate let through.
- Referrals arriving without the administrative detail the clinic requires, grouped by source, so the gap is fixed where it originates rather than absorbed by the intake queue.
Named without target values. What good looks like depends on your volumes and your risk appetite, and is set with you rather than asserted here.
The UiPath components this design uses
UiPath Maestro
Runs the BPMN process and holds its state for as long as the work takes, including while it waits on a person or a system that is down.
UiPath Agent Builder
Where each agent is defined — its instructions, its tools, its inputs and outputs, and the escalation that sends work to a person.
UiPath Document Understanding
Classification and field extraction, returning a confidence score per field that the policy gate can route on.
Context Grounding
A retrieval index over your own policies and reference data, so an agent cites the rule it applied instead of recalling it.
UiPath Action Center
Where a human step actually lands. The approver gets a task with the agent's reasoning and sources attached, and the process resumes on their decision.
UiPath Orchestrator
Schedules the robots, holds queues and retries, and issues the least-privilege credentials each automation runs under.
UiPath Integration Service
Connectors to the systems of record, so the process talks to them through a maintained integration rather than a bespoke script.
Systems it touches
- Patient administration system and its scheduling module
- Master patient index
- Coverage or scheme eligibility service
- Referral channel — portal, exchange feed or monitored mailbox
- Patient notification channel
What the run leaves behind
- The referral as received, and the administrative fields read from it
- Every candidate patient record considered, and which one the match resolved to
- The coverage check, its result, and the scheme rule applied
- Who confirmed the registration or changed the slot, on what basis, and when
- The appointment reference written back to the referring source
Other representative workflows
Talk to us about a process like this.
The most useful first conversation is about a real process — where it stalls, who approves what, and which systems it touches.