The denial statement is still worked by hand. That is where the money is.
Your RCM module already validates claims before they reach NPHIES. What happens after the payer responds is different work — every denied claim opened one by one, every service line justified separately, by people with a clinical background. Revenue Guard automates that side of the cycle, inside your own infrastructure, with your physicians approving anything clinical.
Two leaks, and only one of them is visible
Denials — the one you already measure
Initial rejection rates reported by KSA providers run at 20–30% of submitted claims. After correction and justification the market average settles around 15%. Large providers push their final rate to 5–10%. Smaller polyclinics, with less negotiating weight, live at 20–25%.
That closing gap is not free. It is produced by billers, coders and denial-management staff with clinical training, opening claims one at a time. The difference between your initial and final rejection rate is a payroll line.
Underpayment — the one you don’t
A claim can be paid in full and still be short. Bill above the contracted net price and the payer settles down to the contract. Miss the co-payment at reception and the payer pays only its own share, leaving the rest for you to chase from the patient.
Neither is a denial. No denial statement arrives, no review is triggered, nothing lands in the rejection report. The money is simply not there at reconciliation, and by then the encounter is months old.
Ranges from 2026 interviews with revenue-cycle leaders at private providers, TPAs and payers in KSA, and from published research on claim rejection in KSA hospitals. Rates vary by provider size, payer mix and specialty.
Everyone validates before submission. Almost nobody works what comes back.
Pre-submission checking is a solved problem in this market. RCM modules assemble the JSON. Clearing houses return a claim before it reaches NPHIES when a medication does not match the diagnosis. Larger providers run their own pharmacy benefit management. Payers rebuild the same rule engines on their side.
The response is where the market stops. When the denial statement arrives it is read claim by claim and service line by service line. Some lines need a missing pre-authorization retrieved. Some need a technical correction. Some need a physician to write a clinical justification and resubmit as a related claim.
Repetitive work that requires clinical judgement — which is exactly why it has stayed manual, and exactly why it is expensive.
Recovery first, prevention second
- 01
Read the denial statement
Ingests the payer response and classifies every denied and short-paid line by reason. The queue is ranked by recoverable value, not claim count — a denied service costs margin, a denied medication costs cash, because the drug was already bought from the supplier.
- 02
Assemble the justification
For each line, pulls the supporting evidence already sitting in your systems — the encounter record, the prior authorization, the lab or radiology result, the prescription — and drafts a case against the applicable CCHI and MOH guidance.
- 03
Route to the physician
Anything clinical goes to a named clinician as a prepared justification to approve or edit. Nothing is submitted on a physician's behalf without that approval, and every step is logged.
- 04
Resubmit and reconcile
Files the corrected related claim, then reconciles expected against adjudicated against paid, so short payments surface as a number instead of disappearing into the ledger.
- 05
Close the loop
Groups recurring denial reasons into root causes, so next month's claims stop failing for the reason last month's failed. This is the monthly root-cause analysis your RCM team is doing on a spreadsheet today.
Payers ignore generic answers
Respond to the same denial code with the same paragraph twice and the payer treats it as boilerplate and stops reading. A justification only lands when it is built from the specific case — the patient’s age and sex, the clinical findings, the history, the guidance that actually applies.
That is a per-claim reasoning problem, not a mail-merge problem. Revenue Guard builds each response from the record in front of it and cites the standard it relies on, so the reviewer on the other side has something to act on.
Patient data does not leave your perimeter
Some vendors describe their denial handling as automation and are in practice forwarding claim content to a public chat model, with the provider asked to hold the subscription. Patient data leaves the Kingdom and the provider carries the exposure.
Revenue Guard runs where your data already lives — on-premise, or in a Kingdom-local cloud with the database held locally. The models run inside that boundary. Nothing is sent to an external inference service, and there is no per-page or per-token document charge.
Primo RPA has run this deployment pattern in regulated environments for eight years, including a full production migration of a Tier-1 banking robot fleet to Linux without interrupting a single business process. See deployment architecture →
No replacement, no migration
In most KSA providers the HIS and the RCM solution come from different vendors, the integration between them is partial, and staff finish the job by hand at submission time. Adding a third system that demands its own integration project is not a serious proposal.
Revenue Guard sits on top of what you run. It works through available APIs, secure file exchange, or the application interface itself when no interface is offered — the same approach Primo RPA robots use in banking and industrial environments where core systems cannot be touched.
Deployment does not require a change to your HIS, your RCM module, or your NPHIES connection.
Written for the person who owns the reimbursement number
Across the market, total reimbursement lands at roughly 50–55% of gross billed value once contractual discounts of 25–45%, volume discounts and prompt-payment discounts are applied. That percentage is the number an RCM director is measured on. Above it is overachievement. Below it is a problem with a name attached.
In this market price is not a lever — no payer accepts a tariff increase when there is another provider available. Reimbursement is the lever.
Revenue Guard reports in that unit: recovered value, recovered lines, days to resolution, and the reasons that keep repeating — against the reimbursement rate, not against a bot-utilisation dashboard.
Start with your own denial data
The first step is a free opportunity analysis of claim- and service-level denial data from a period you choose. It produces three things: the recoverable value sitting in that period, the denial reasons that produced it, and what the same period would have looked like with Revenue Guard in place.
You keep the analysis whether or not anything follows it.
Deployment on-premise or in Kingdom-local cloud. Works alongside your existing HIS, RCM module and NPHIES connection.