Settling the claims the rule table resolves, and sending the rest to an assessor
Adjudication rules do not hold still. Benefit limits, exclusions, waiting periods and documentation requirements are revised by people who do not write software, and the next revision usually arrives before the last one has finished working its way through the process. Run as one orchestrated process, those rules sit in a decision table that is versioned and edited on its own, and a claim is judged against the version that was in force on the date it relates to. Claims the table resolves settle without a person. Everything else reaches an assessor with the rule it stopped on and the page the value came from.
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 claim is submitted through a member portal, a provider system, a broker file, or a scanned form that arrives by post.
Why it is orchestrated rather than scripted
- A claim can sit waiting on a missing document or a provider's reply for longer than any single automation run, and the instance has to stay open with its state intact.
- The adjudication rules change on their own schedule, so the claim has to be judged against the version in force on its date of service rather than the version deployed today.
- A declined claim can be appealed, which means the table version, the inputs it received and the clause that produced the outcome all have to be reconstructable long after settlement.
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
Claim submittedSystem
A claim form and its supporting documents arrive from a member portal, a provider system, a broker file, or a scanned submission.
- 02
Read the claim fileAgent
The form, invoices, reports and identifiers are classified and extracted into one claim with a line per item claimed, each field carrying a confidence score.
- 03
Check cover and entitlementAgent
Cover in force on the date of service, membership status, waiting periods, exclusions and the limits already consumed are established before any rule is applied.
- 04
Settles under the rules?Maestro
The orchestrator runs the claim through the decision table for that plan and version, and routes on what the table returns line by line.
- 05
Assessor reviewPerson
Any line the table left unresolved, and any claim above the straight-through amount, reaches an assessor with the applied rules and the source pages attached.
- 06
Settle and notifyRobot
The result is written line by line to the claims system, a payment instruction is raised for the settled amount, and the outcome goes back to the claimant.
- 07
Settled and recordedSystem
The claim is closed, and the inputs, the table version, the outcome per line and any assessor 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.
Claim Intake Agent
Turns a claim pack into a structured claim with one line per item claimed.
Reads
- The submitted form and every attachment that came with it
- The document set the benefit being claimed requires
- Coding and item reference data the claim lines map to
- Earlier claims filed under the same membership
Decides on its own
Must escalate when
Adjudication Agent
Assembles what the decision table needs for each line — the plan version in force on the date of service, waiting periods, exclusions and the limits already consumed — and names any line the table cannot be run against.
Reads
- The structured claim and the plan in force on the date of service
- The adjudication decision table for that plan, at the version then current
- Benefit limits already consumed in the period
- Policy wording indexed for retrieval
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.
Claim record robot
Opens the claim in the claims system, files the documents against it, and writes the adjudicated outcome line by line.
Runs in
Settlement robot
Raises the payment instruction for the settled amount and writes the reference back onto the claim.
Runs in
Settles under the rules?
Cover was in force on the date of service, every line resolved to an outcome in the table version that applies, no limit was breached, and the total sits under the straight-through amount for that benefit.
- Passes
- Settled and instructed for payment without an assessor.
- Does not pass
- Held for an assessor, with the unresolved lines flagged and the process kept open until a decision 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 make the clinical judgment. Where the outcome turns on whether care was appropriate, the claim goes to a person qualified to say so.
- It does not edit the rule table. Agents read the table; changing a rule is a versioned act performed by the people who own the plan.
- It does not release money. A robot raises the payment instruction; releasing funds stays inside the finance system's own approval chain.
- It does not decide fraud. Duplicates and unusual patterns are flagged with what triggered the flag, and handed to the team that investigates them.
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 claims administration system is unavailable when the claim needs to be opened or written back.
- The instance holds at that step and the work stays on an Orchestrator queue rather than failing the claim. It resumes at the same step when the system answers. The submission is already recorded, so the date the claim was filed does not move.
- A field comes back below its confidence threshold, or the agent cannot map a claim line to a known item.
- The line is marked unresolved rather than guessed. The claim continues through the lines that did resolve, and the unresolved ones go to an assessor with the document page they were read from.
- The assessor never acts on the task.
- The task stays open in Action Center and ages. On the interval the process defines it is reminded, then reassigned to the next holder of that authority. No claim is settled or declined by a timer running out.
- The decision table is republished while claims are in flight.
- In-flight instances keep the version they started under and finish on it. Re-running a claim against a newer version is an explicit act, and both outcomes stay on the record with the version that produced each.
Data, rollout, and what to watch
Data it touches
- The claim carries personal and, in health administration, clinical detail. Documents stay in the organization's own store, and agents are passed the fields and references they need for the step rather than the whole pack by default.
- The process, its queues, its document store and the retrieval index over the plan wording are deployed in the region the organization's rules require, and the index is built from the organization's own documents.
- The adjudication agent sees claim lines, plan terms and limits consumed. It does not see bank details; those pass between the claim record and the finance system through a robot, under credentials the agent does not hold.
- Retention follows the claim's own lifecycle, including the appeal window. The audit record outlives the settlement by the period the organization sets, and extracted copies are removed on the same schedule as the source they came from.
How it goes live
- 01
Shadow
The process runs on live claims beside the existing team. Every claim is adjudicated twice — by the table and by a person — nothing is written back to the claims system, and the two outcomes are compared line by line. The gate to the next phase is that the disagreements are understood rather than counted: each one traced to a rule, an extraction, or a claim that is genuinely ambiguous.
- 02
Supervised
Outcomes are written to the claim, but every claim still reaches an assessor who confirms or changes the result before it settles. What they change is the working list of rules that need rewriting. A benefit moves on when its corrections stop coming from the table and start coming only from the claims themselves.
- 03
Unattended with exceptions
Claims that clear the table settle without a person, one benefit at a time rather than all at once. Anything the table leaves unresolved, anything above the straight-through amount and anything the plan reserves still goes to an assessor. A benefit can be put back into supervised mode on its own while its rules are being rewritten.
Signals worth watching
- The share of claims that reach an assessor, and whether it moves after a rule table is republished.
- Which rule in the table most often produces the line an assessor overturns.
- The age of open tasks in Action Center, and whether particular benefits or assessors accumulate them.
- How often a settled claim is reopened or appealed, and whether the cause traces to the extraction or to the rule.
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
- Claims administration system
- Membership, plan and policy data
- Member, provider or broker submission channel
- Finance system for payment instructions
- Document store
What the run leaves behind
- The claim pack as submitted, and every field extracted from it
- The decision table version in force at the moment of adjudication, and the inputs it received
- Each line's outcome and the rule that produced it
- The assessor's decision, their reason, and the line it applied to
- The settled amount, the payment reference, and what was written back to the claim
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.