Prior authorization in the UAE and Saudi Arabia: a workflow that stops leakage

Prior authorization (pre-approval) in the UAE and Saudi Arabia means asking the insurer to approve a planned service before you deliver it. In Dubai this runs through eClaimLink, and in Saudi Arabia through NPHIES. The money is lost when approvals are raised late, expire unnoticed or never reach the booking. A shared register inside your medical billing software fixes most of it.

This article sets out a workflow that works in both markets: who owns each step, what to record, and how to stop a service being delivered without a valid approval. For the Saudi rails in more depth, read our NPHIES guide for providers.

Where prior authorization leaks money

Prior authorization failures rarely show up as a single dramatic loss. They show up as a steady trickle of denials and awkward conversations. The usual patterns:

• Raised too late. The request goes in on the day of the procedure, the payer has not answered, and the clinic either delays the patient or proceeds at risk.
• Approval expired. The approval was valid for a set window, the surgery date moved, and nobody noticed.
• Approved something different. The payer approved one code or quantity, and the clinic delivered another.
• Approval never linked. The approval number sits in an email or a portal, but not on the claim, so the claim is denied anyway.
• Decision lost. The doctor decided on a procedure, the patient left, and nobody raised the request or booked the case.

Each of these is a process gap, not a payer problem. The fix is to treat prior authorization as a tracked piece of work with a clear owner, not a side task for whoever is at the desk.

How it works in each market

Rules on which services need approval, and how long approvals stay valid, differ by payer, plan and policy class. Keep a simple table per payer of what needs pre-approval, and update it when contracts change. Do not rely on memory; staff turnover will erase it.

In Saudi Arabia, the patient's policy class matters. It drives deductibles, co-pay and the approval limit, so the class must be on the patient file before services are added. In Helix, a Saudi patient cannot be billed against a policy without a class, which stops that problem at the source.

A seven-step prior authorization workflow

1. Capture the decision in the chart. When the doctor decides on a procedure, surgery, imaging study or expensive drug, record it as a decision, not just a line in the plan.
2. Check whether the payer needs approval. Use your payer table. If unsure, assume yes.
3. Raise the request the same day. Include the diagnoses, the requested codes and quantities, and the treating clinician. Attach the clinical justification the payer will want.
4. Record it in one register. Every request, its status, the payer's reference, the approved services and the validity window. One place, visible to billing, booking and the doctor.
5. Gate the booking. The procedure is not confirmed until the approval is on file and the planned date falls inside its validity window.
6. Chase what is pending. Review pending requests daily, oldest and highest-value first. Keep the patient informed.
7. Carry the approval into the claim. The approval reference and approved services flow onto the claim for the same encounter, so the payer can match them.

Who owns what

Handling rejections and partial approvals

A rejected or partly approved request is not the end. Read the reason first. If the payer asked for information you have, resubmit with it. If the payer approved a different service or a lower quantity, the doctor decides whether that is clinically acceptable. If the service is excluded, the patient needs a clear explanation and a self-pay estimate before anything happens.

• Record the payer's decision, reference and any denial code against the original request. Keep earlier answers; do not overwrite them.
• If the clinical plan changes, raise a new request rather than stretching the old approval.
• Tell the patient in plain language what was approved, what was not, and what it means for their bill.

How Helix supports prior authorization

Helix treats prior authorization as part of the patient record, not a separate portal. It connects to eClaimLink/DHPO in Dubai and to NPHIES (via Waseel) in Saudi Arabia, and it keeps a prior authorization register for every request the branch raises.

• One register. Each request holds the patient and policy, encounter, diagnoses, requested activities with the clinician's licence number, and the payer's decision with its reference, validity dates and any denial code. Every answer is appended to the history.
• Decisions tracked until booked. The Clinical Decisions Hub in the EMR tracks every decided surgery, referral and follow-up until it is actually booked, so a decision cannot quietly disappear.
• Pending requests chased. Verto ranks pending requests by age and value and drafts a short, consent-checked update for the patient. Staff approve each message before it is sent.
• Approvals flow into claims. The approval travels with the encounter into the claim, so the payer can match them.

For clinics working in the Kingdom, our Saudi Arabia compliance page explains how NPHIES and ZATCA Phase 2 fit together. For the Dubai and Abu Dhabi rails, see UAE compliance. And because a missing or expired approval is one of the most common denial causes, pair this workflow with our guide to reducing claim denials.

A weekly prior authorization review

• How many requests are pending, and how many are older than your target?
• Which approvals expire in the next two weeks, and are those cases booked?
• Which rejections came back, for what reasons, and from which payers?
• Were any services delivered without an approval on file? Why?

Four questions, fifteen minutes. Most clinics find that the answers point to the same two or three gaps, and closing them is where the money comes back.