A Dubai-based private hospital group running 3 hospitals and 8 clinics was dealing with over 3,000 insurance claims weekly from 25+ insurance providers in the UAE. Their pre-authorization process was situated in the middle of patient care, insurance regulation, and revenue cycle management. If a patient needed more than a simple consultation, the hospital had to verify eligibility, collect clinical documentation, submit a prior authorization request through the applicable insurer’s portal, address follow-up inquiries, and wait to be authorized before the treatment could move forward. The whole thing was manual, tailored to each insurer, and slow.
The 12-person team tasked with insurance coordination spent its days verifying insurance cards, decoding coverage, pulling medical records, managing dozens of insurer portals, and tracking down status updates. Standard wait times for a lot of procedures are 24 to 48 hours to get the approval going ahead. Complex cases could take around 3-5 days. About 15 to 20 % of first submissions are rejected or are returned with requests for additional information., leading to delays which frustrate patients and disrupt treatment planning. Emergency treatments were often done before approval, which later led to retrospective denials totaling millions every year.
At aTeam Soft Solutions, we developed an AI agent that does pre-authorization package assembly, submission via insurer-specific portals, denial prediction, appeal drafting, and offers real-time status tracking. The outcome was a functional hospital revenue cycle AI system that minimized standard pre-authorization turnaround from 24-48 hours down to 15 minutes, raised first-submission approval rates to 95%, minimized emergency claims denials, and provided the hospital group a greatly enhanced insurance operations department without adding personnel.
Before this project, the hospital group’s insurance team wasn’t having a hard time because it wasn’t trying the efforts or because it didn’t have domain expertise. The issue was that the workflow itself was too fragmented, too portal-dependent, and too reliant on human memory and insurer-specific expertise.
There were patients all day long showing up to have procedures, diagnostics, therapies, surgeries, and treatment plans that needed to have insurer approval in advance. When a treating physician determined that a procedure or service was necessary, the process of coordinating insurance began. A coordinator first verified the patient’s insurance card, policy information, and eligibility status. That sounds simple, but in practice, it meant checking on payers, plan types, network statuses, referral requirements, exclusions, waiting period limitations, and policy validity. Even before clinical review began, the team had to find out whether the patient was eligible and whether the hospital could make a submission.
Then it was on to coding and documentation. The coordinator was required to identify the appropriate CPT and ICD-10 codes for the proposed treatment, at times in consultation with the clinicians, particularly in cases when the coding could materially impact approval results. Then they had to gather the documentation to support that. This was often referral notes, consultation reports, lab results, imaging reports, operative indications, prior treatment history, and, in some cases, forms specific to the insurer or attachments specific to the specialty.
This was the point at which the pace slowed down sharply.
Each of the 25+ insurance companies had its own habits. A few of them needed certain documents in a strict format. Some required labs are from within a certain time period. Some specified certain procedure-specific templates. A few asked for explanations that you wouldn’t find in a standard clinical note. Some also seemed more inclined to challenge physiotherapy, orthopaedics, high-cost imaging, chronic disease management, or ongoing courses of treatment. The experienced coordinators knew these rules by heart. Not so new staff.
Once the paperwork was in order, the coordinator had to log in to the insurer’s portal to submit the request. There was no common pre-authorization process across payers. Different portals required different fields, had different layouts, different navigation routes, and different rules for uploading. Some of them were very responsive and structured. Most of the people were clumsy and outdated. Somehow still accept submissions by email or fax in certain circumstances. The hospital group’s HIS could generate some simple forms for the applications, but it could not connect to insurer portals, meaning all the portal work ended up with human agents rather than being routed to them.
Now the wait began after the submission.
The coordinator had to repeatedly check the status or wait for a response. Insurers frequently returned queries: submit a missing report, clarify the diagnosis, provide more current labs, justify medical necessity, or fix a code mismatch. Each extra query meant more delays, more back-and-forth, and more work for the administrators. Then the coordinator had to go back into EMR, collect the requested information, write a response, and resubmit/update the case. In the meantime, the patient was waiting, clinicians were waiting, schedulers were waiting, and the hospital’s cash realization was being delayed.
Ordinary cases were processed within 24-48 hours on average. Complex procedures that require medical review may take 3-5 days. That delay was not without its real consequences. Patients sometimes left for competitors rather than wait. Treatment plans were being delayed by administrative uncertainty, and clinicians were frustrated. The reception and scheduling staff had to apologize for delays beyond their control. In emergencies, the hospital tended to treat first and make their case afterwards, which is clinically appropriate, but financially risky. The body was challenging us with AED 2-3 million each year in rejected emergency claims because retrospective documentation and authorization defense were inconsistent and lacking.
The most critical point was that the knowledge was not equally spread among the team. A few coordinators for certain insurers, because they got to know the peculiarities of those portals and the particular attitude of those medical review teams. That allowed us to create knowledge silos. When the appropriate coordinator was not available, the case was held up, slowing down. When a coordinator quit from the organization, they took the knowledge with them.
For a Dubai hospital group that processes AED350 million in annual insurance revenue, this was not viable. The company required a procedure that would allow it to grow and would not depend on the memory of the individual, portal know-how, or the good fortune of the moment of having the right personnel available.
That’s where aTeam Soft Solutions came into the picture. The objective was not merely to speed submission. It was about making insurance authorization a managed, explainable, and ever more proactive workflow.
The client had attempted to work around the issue using its own systems, but those solutions were designed for related tasks, rather than executing pre-authorization from start to finish.
The HIS and other related claim generation mechanisms could produce some basic claim data, but they were unfamiliar with how to use insurer-specific portals, understand changing documentation requirements, or manage the variation from insurer to insurer that is pre-authorization in the UAE. They are excellent as data inputs, not as a process automation layer.
Standard RPA also wasn’t enough. Simple browser bots only work well when the user interface is stable and predictable. These were not the insurer portals. Layouts have changed. Security steps have changed. Upload requirements have changed. New required fields were added. Static automation scripts that rely on brittle selectors would break every time a portal page was updated. Writing and maintaining individual scripts for 25+ insurers would have meant a full-time job in maintenance.
Generic claims automation products also failed to address the underlying issue. They were useful for forms and maybe for batch submissions, but they had no sense of clinical significance. A radiology report isn’t just a PDF that you attach. It is proof that may or may not back up the procedure being requested. A lab result might be important for one insurer, but not for the next. “Patient complains of pain” is not a clinical justification associated with the correct diagnosis and a history of prior treatment.
That’s why the client required an insurance pre-authorization AI agent as opposed to a rules script or OCR workflow. The system needed to learn about clinical and insurer behavior. It had to have a sense of what information to collect, what information was missing, which information each of the multitude of insurers required, the submissions they were most likely to reject, and how to bolster weak cases before they ever submitted. This, in effect, was a true AI healthcare claims automation and denial-prevention problem and not simply portal automation.
We developed the solution in stages because healthcare revenue processes demand trust, particularly when they involve clinical documentation, payer communication, and timing of patient treatment. The hospital system was looking for immediate improvements in speed, but it also needed to be confident that the system would enhance the quality of approval, not just submit more quickly.
The first stage involved building the best possible submission package before any portal activity.
We connected the AI agent with the hospital’s HIS and EMR using HL7 FHIR-based data access methods to access patient demographics, payer information, diagnoses, procedure plans, physician notes, lab results, radiology reports, referrals, and more relevant clinical artifacts. That eliminated one of the biggest manual headaches for the coordinator team: hunting through systems for documentation and figuring out what to attach.
But the real benefits didn’t come simply from collecting the documents. It resulted from tailoring the bundle to the insurer.
The AI agent retained the insurer-specific documentation requirements learned from 12 months of accepted and rejected submissions. For instance, it knew that an insurer anticipated a specific referral format, was more stringent regarding how recent lab data was, and habitually requested procedure-specific attachments in the case of orthopedic or imaging-related approvals. Instead of creating a generic packet for all payers, the system generated a submission package customized to the rules and preferences of the particular insurer.
This stage included completeness checking as well. The system checked for missing dependencies before the coordinator even viewed the packet. If the insurer typically needed a radiology report for a particular procedure code and the patient file had only labs, the system explicitly alerted to that. It didn’t for denial. It informed the coordinator what was missing and what to ask for before submission.
That one change improved quality as workflows were transformed from reactive corrections to proactive preparations. Coordinators didn’t have to rely on memory or case-by-case intuition related to each insurer. They looked at a prepared package, saw what the system had put together, then signed off with little effort.
After the package assembly logic was stable, we went into portal execution.
We created a browser automation framework with Playwright, but it didn’t rely completely on fixed selectors like fragile RPA. The AI agent employed form-label matching, contextual field recognition, and visual cues, which allowed it to adapt more gracefully when a portal was modified. This was critical as the insurer ecosystem in Dubai is non-uniform for pre-authorization processes. A fix that worked just until the next UI update came along would not do.
The layer of submission took care of login, form filling, document uploads, and confirmation capture for each insurer. For those companies that still took email submissions under certain circumstances, the system would format an email, attach the appropriate documents, and generate the message in the proper format. The coordinator would have the option to preview, and the system would also be able to act automatically for known scenarios with the necessary safeguards in place.
The status tracking was implemented in the same layer. Rather than having coordinators manually check each portal, the AI agent tracked submission status and relayed updates back into the hospital’s tracking system. When an insurer posted a query or asked for further information, the system surfaced it right away, pulled relevant information from the EMR, and composed a response. This made follow-up a structured review step instead of a manual hunt.
Meanwhile, the hospital began to experience the first significant speed gains. The turnaround time reduction was not just because of faster portal entry. It was due to more complete submissions, less missing paperwork, and fewer unnecessary queries to the insurer.
Phase three turned out to be the best part of the entire project.
With over 50,000 historical pre-authorization results, we developed a predictive layer that predicted the likelihood of an approval before submission. The AI agent could tell which cases were going to be approved quickly and which were going to be denied, delayed, or queried.
This was important because the hospital wanted more than just a quicker turnaround. It wanted better submissions and fewer rejections.
The workflow could be accelerated for high-probability approvals, since the documentation and style of coding resembled previously successful cases. For the less robust cases, the AI agent brought to light the probable risk drivers. It might say, for example, that an insurer was known to deny long-term physiotherapy requests above a certain point unless recent surgery or strong medical need was documented. Or it might highlight that an imaging request is supported weakly, based on the fact that the findings cited to justify the intervention don’t clearly warrant the intervention sought.
Then, the system helped to reinforce the submission. It recommended additional supporting documentation, asked for a stronger rationale, and, in some instances, clinically accurately coded among the valid alternatives and based on historical approval outcomes, optimized. It never invented diagnoses or changed medical intent. It chose the most powerful compliant presentation of the case from previous success templates.
This is also where the denial appeal assistance got so much stronger. When a denial was received, the AI agent reviewed the insurer’s rationale, compared it to historical appeal results, and composed an appeal letter with a stronger evidence pool. The coordinator still reviewed it, but the process became quicker, more uniform, and way more in-depth.
At aTeam Soft Solutions, this is the stage that transformed our perspective on healthcare payer processes. A denial prevention is more valuable than processing one quickly after the fact.
Eventually, the system evolved to an earlier point in the patient journey.
Even before a patient visited the doctor, in many standard protocols, the agent could conduct real-time eligibility checks and reveal coverage status, annual limits, co-pay responsibility, excluded services, and waiting period restrictions. This allowed the front office and financial counseling staff to see clearly much sooner.
We also added pricing estimations. According to the estimated treatment, the known coverage situation, and the remaining limits, the system calculated the estimated out-of-pocket exposure for the patient. This allowed for a better patient experience, as the hospital could be more direct in what patients could expect to pay rather than relying on insurer processing.
When the treatment was complete, the very same operational logic carried through to final claim crafting and submission tracking. That created a revenue cycle continuity. The hospital was no longer treating pre-authorization and claims follow-up as two separate manual processes — the hospital was treating them as a single, automated function. An AI agent was included as part of the fuller medical claims process automation layer encompassing pretreatment and post treatment procedures workflows.
The backend is implemented in Python with FastAPI, with Celery and Redis used to manage asynchronous jobs that perform package building, portal submission, query retrieval, and insurer status checks. Structured case data, payer rule sets, historical outcome patterns, portal configurations, and audit history were stored in PostgreSQL. Files and submission artifacts were saved in S3.
HL7 FHIR was utilized for EMR and clinical-system integration, enabling the AI agent to access the patient and clinical context needed for each pre-authorization case. This encompassed diagnosis information, planned procedures, notes, results, and documents without manual querying by coordinators to fetch every item.
For the portal execution, we leveraged Playwright as the hospital group required strong browser automation on multiple insurer portals. But Playwright was not the answer by itself. We put a generic insurer portal framework over it. Routine tasks like login, search, form fill, upload, submission, and status checking were encapsulated into reusable activities, while variations per insurer were held within configuration and rules layers. This enabled us to reduce the cost of adding new insurers and adapting to changes in the portal significantly.
Claude managed clinical document review, drafting of correspondence, package QC, denial prediction explanations, and drafting of appeals. This mattered for all support documents, but particularly in situations where the system needed to ask whether the supporting evidence really was for the requested procedure, not just if a document was there.
A React dashboard provided coordinators and managers a single real-time view across all insurers, cases, stages of approval, responses to queries, and risk flags. Rather than splitting labor by insurer memory and portal know-how, the team was able to handle the entire queue from a single interface.
All operations were auditable. Package packing, missing-documents detection, submission actions, portal responses, appeal drafts, approval-likelihood scores, and human interventions were logged. In healthcare finance, that kind of traceability is mandatory. That’s one of the reasons aTeam Soft Solutions develops every agentic AI healthcare dubai workflow with clear audit and override mechanisms from the start.
The portal issue was big enough by itself. Over 25 insurers’ portals translate to 25+ interface behaviours, login patterns, upload rules, and required-field combinations. Writing one-off automations for all of them would have resulted in a brittle and costly system. That’s why we created a generic insurance portal framework with insurer-specific configuration. Once that base existed, modifying or adding an insurer was far quicker and safer.
Interpretation of clinical notes was also a challenge. A report is not helpful just because it is there. The system needed to determine if a lab result, referral, or MRI finding truly supported the procedure being requested. That took a far more clinical reading of the record than, say, routine document automation. We trained the prompts and validation flows on 1,000+ examples of successfully packaged reviews by clinical staff so the AI agent could learn the relations between findings and justification.
The payer-rule problem was also deeper than it appeared. The rules of the insurers are seldom all published in one neat, structured document. Most of the actual approval patterns were embedded in the coordinator experience: which payer denies what, what patterns of documentation work, what triggers thresholds review, and which styles of appeal succeed. We conducted structured knowledge extraction sessions with the best coordinators to convert that operational memory into a searchable rules layer that the system could really use.
Cases of emergency retroactive approvals were yet another bracket. They simply didn’t work within the tidy planned workflow of routine pre-authorizations. The evidence of treatment had to be obtained after the care was delivered, and the strongest retrospective case could be built by the system. This is one area where the hospital realized substantial revenue recovery.
The bottom-line result was speed. The average turnaround time for pre-authorization for routine procedures dropped from 24-48 hours to around 15 minutes. That immediately changed the patient experience. Pre-approval for insurance, which had once taken several days to obtain, could now be secured while the patient was in a routine appointment or registration session window.
First-submission approval rates increased from roughly 80-85% to 95%. That matters more than it may seem. It means the hospital was no longer expending so much energy on unnecessary back-and-forth with insurers. Less missing paperwork, more substantiated submissions, and payer-specific training all of these helped to cut down on the friction before it set in.
The coordination team was also greatly altered. The hospital went from 12 coordinators dealing with the volume on a weekly basis to a team of five, overseeing the same 3,000+ claims volume but with more robust process controls. Seven workers were redeployed to patient financial counseling and complex case management instead of repetitive submission tasks.
Denied immediately submitted claims fell by 65% since retrospective documentation submissions were far stronger and more consistent. Recovered annual revenue through accelerated processing, reduced denials, and strengthened appeals was estimated at approximately AED 8 million.
Success rates of appeals have also greatly increased, from around 30% to 62%. This was a significant validation of the denial-appeal-drafting layer. The hospital was just not submitting more quickly. It was protecting its revenue better.
Patient satisfaction rose as well. NPS internal to the experience of the insurance increased from 22 to 54. This is not a minor operational statistic. It’s a reflection of the fact that patients felt less caught in the middle between provider and payer as they waited for approvals.
Most critically, the hospital developed a scalable insurance-operations model. Rather than handoffs involving insurer experts and manual case management, it now has an AI agent that can handle payer variation, package quality, portal submission, denial prediction, and revenue-risk visibility organization-wide.
This solution utilized Python with FastAPI for backend services, Celery / Redis for asynchronous task processing, Claude for clinical-document reasoning and correspondence drafting, Playwright for adaptive insurer-portal automation, custom OCR for reading insurance cards, HL7 FHIR for EMR integration, PostgreSQL for case and rules storage, React.js for the insurability operations dashboard, and AWS EC2, RDS, S3, and Lambda for infrastructure, storage, and event-driven execution.
The biggest takeaway was that denial prevention drives more value than denial management.
In the early days, one was tempted to think that the most visible payoff would be in automation speed. And the speed that did matter. But the hospital revenue cycle team quickly demonstrated that the larger financial impact was in preventing denials before they occurred. It is expensive to have a case denied, not just because of the rework but because of the delay in treatment, staff effort, time spent on appeal, and potential loss of revenue. When the AI agent could say, “This submission is weak; here is why, and here is what should be added,” the value was far greater than rapid portal entry alone.
We also discovered that understanding of payer behavior is frequently trapped in people, not systems. Harvesting that knowledge from the most experienced coordinators and making it accessible to the workflow engine was one of the largest multipliers in the project. It allowed the entire group to be more resilient and made it less reliant on specialist memorization.
And finally, we learned that healthcare teams do not begin to trust automation until it makes them both faster and more clinically coherent. The system was adopted because it was more than a fill-in-the-blanks form. It created more robust submissions that physicians, coordinators, and finance groups could articulate and support.
Private hospital groups in Dubai, the UAE, and the wider Middle East often tend to expect a slow pre-authorization to be simply part of payer operations. Actually, much of the delay can be attributed to fragmented documentation, conflicting insurer logic, portal-heavy workflows, and reactive management of weak submissions.
At aTeam Soft Solutions, we develop realistic environments where an AI agent manages package preparation, insurer submission, denial mitigation, appeal drafting, and status tracking with human oversight where it matters. That’s how insurance operations move from inbox-driven coordination to a true hospital revenue cycle AI workflow that protects both patient experience and revenue.
