ArkCloud Rehab
Utilization review
Authorized against delivered, per episode. It is the screen that turns 'we think we are still covered' into a number, before the visits that were not covered become unbillable.
Written for: Utilization review · Rehab operations · Clinical supervisors · Billing teams
What it answers
Launcher → ArkCloud Rehab → Records and revenue → Utilization review
Every episode is delivered under an authorization that approves a number of visits or days. This screen compares that approval against what has actually been delivered, so that an episode approaching its limit is visible while something can still be done about it.

Real screen · synthetic data. Utilization review lists each episode under review with what was authorized and what has been delivered against it. The gap between the two is the operational signal.
/rehab/utilization-review
Why the gap matters
A visit delivered beyond an authorization is usually not payable. The clinical work still happened and still has to be documented; what is lost is the ability to bill for it. Because the loss is discovered later - at charge capture, or at denial - it is easy for it to be discovered repeatedly.
Recording an authorization, a determination and a call
Authorizations are recorded from the episode they belong to, not from this list. Both the patient and the course of care are already known there, so neither can be attached to the wrong one.
- Record the authorization with the number the payer issued, the dates it covers and what was granted. Once it is approved, services delivered under it are no longer held for authorization. They still need a signed note and the other billing checks, and a charge is created only when a person with fee-management permission posts it from charge capture.
- Record the determination when the payer answers. A partial approval replaces the quantity that was requested, because billing follows what was granted rather than what was asked for.
- Record the contact every time somebody speaks to the payer, whether or not it produced a decision.
ArkCloud does not generate authorization numbers. The number is the payer’s, it is what a claim and an appeal are filed under, and an invented one matches nothing on their side.
A payer authorizes in one currency — days, visits or units. The form asks which, rather than offering three boxes, because an authorization carrying two quantities would have a remaining balance that counts the wrong one.
An approved authorization needs a quantity or an end date. With neither it would authorize unlimited billing that never expires, which no payer issues, so it is refused.
Used days, visits and units are not editable. They are maintained from posted charges, so the remaining balance is derived from what was actually billed rather than from a number somebody typed.
A contact that reached no decision — a peer-to-peer that went to committee, a call that reached nobody — is recorded as no decision yet. That is a real and common outcome, and it is the kind of record an appeal leans on hardest.
What to do about an episode near its limit
- Confirm the clinical need. Whether further care is warranted is a clinical question and comes first.
- Seek further authorization where care should continue. This is a payer conversation; ArkCloud records the outcome rather than conducting it. There is no 278 transaction and no payer-portal integration — every determination here was recorded by a person who did the work elsewhere.
- Consider a step down in level of care where a lower setting is clinically appropriate. Recorded on the episode as a step-down rather than as an edit.
- Plan discharge where the episode has reached its end, with the reason and aftercare plan recorded.



