ArkCloud Access
Eligibility and prior authorization
Access checks eligibility with the payer through your clearinghouse, records the benefits a payer states by phone or portal, and tracks prior authorizations from request to determination. It never simulates an answer, and it does not transmit authorization requests.
Written for: Patient access teams · Evaluators · Implementation teams · Revenue cycle leadership
Obtained, recorded, or nothing
A coverage answer is something people act on: a patient told they are covered goes ahead with treatment, a clerk told an authorization is on file books the visit. So every answer Access shows says where it came from.
| Field or control | What it means |
|---|---|
| Obtained | Access asked the payer through the clearinghouse and the payer answered (a 270/271), in real time or as a batch through the clearinghouse mailbox. Shown with the date it was answered. |
| Recorded | A person established the answer - by phone, fax or the payer's portal - and entered it, labelled with how and when. Benefits verifications and authorization determinations are recorded. |
| Nothing | Nobody has asked yet, or the check could not be made. Shown as blank and unanswered - never filled in with a plausible guess. |
Eligibility checks
Launcher → ArkCloud Access → Eligibility
Eligibility with no clearinghouse connected: the screen says no payer can be asked, and a past check made without one is labelled simulated with its figures withheld.
Not yet usable. This capability is implemented and cannot be used until something outside the software exists - published clinical content, or a live payer or payment connection. The screen states the reason rather than offering a control that would fail.
/access/eligibility
Find the patient and choose the date of service, and Access sends a 270 eligibility request for their coverage to the payer through the clearinghouse and stores the 271 that comes back - active coverage, copay, deductible and out-of-pocket, and whether the plan says authorization is required. Each check keeps its history, so the answer for a given date can be found again.
With a real-time connection (Availity) the answer comes back while you wait. Without one, but with the clearinghouse mailbox configured, the check is queued instead: it is sent within 15 minutes as part of a batch 270 through the mailbox, and the payer's 271 is recorded when it comes back - usually hours later. Until then the check is labelled "Queued for batch" and shows no coverage. An answer that comes back this way is read and shown exactly like a real-time one.
| Capability | Status | What that means here |
|---|---|---|
| Electronic insurance eligibility checks | Needs an external connection | Built as a real payer inquiry, never simulated into an answer. Not connected on the hosted service today, so no eligibility answer is returned.Requires: Availity credentials, or a clearinghouse mailbox, configured for the deployment. |
| Benefits verification by phone or payer portal | Available | Staff record what the payer said, how and with what reference. It supplies the copay and counts visits against plan limits; it is not an electronic eligibility answer. |
| Prior authorization tracking | Available | Requests and approvals are tracked by hand in visits, days or units. Nothing is sent to the payer electronically. A missing authorization never blocks care; it holds the charge. |
| Recording insurance coverage | Available | Staff record the patient's coverage (primary, optional secondary, or self-pay) in the episode's billing setup. Patients cannot edit coverage; a reported change becomes a task. |
Benefits verification
Launcher → ArkCloud Access → Benefits
The benefits worklist: patients with a visit coming up and no current verification, each with a form to record what the payer stated.
/access/benefits
Most therapy practices verify benefits by phone. Access lists the patients with a visit coming up and no current verification, and records what the payer stated: copay, coinsurance, deductible, out-of-pocket, network status and the plan's visit limit, with the call reference. It is a record of what the payer said, labelled as such, and it is never presented as an eligibility response.
Benefits are recorded against an episode of care in ArkCloud Rehab, so this needs Rehab as well. The recorded copay is what online check-in asks the patient to pay, and the visit limit is what online booking enforces.
Prior authorization
Launcher → ArkCloud Access → Authorizations
Prior authorizations from request to determination, with visits used against visits approved and the ones about to run out listed first.
/access/authorizations
Access tracks each authorization from request to determination: the payer and the service, every contact with the payer and its reference, the decision, the approved window and visits, and the visits used against them - with the ones about to run out or expire listed first.
Delivered-against-authorized is also tracked in Rehab's utilization review, on the same authorization records.