One Platform Across Three Emirates: How Multi-Branch Groups Connect Every Site

A clinic group in the UAE grows across emirates almost by default: a polyclinic in Dubai, a dental branch in Sharjah, an aesthetics branch in Abu Dhabi. Each emirate uses a different health information exchange and, often, a different claims platform, and the easy path is three systems, three logins and a spreadsheet to see the whole business. Multi-location clinic software built for this runs the group from one account and connects each branch to the systems its emirate uses, which is what this post walks through: the account structure, the patient file, the inbox, the per-emirate connections and the onboarding order.

The problem with one system per branch

Practice-owner reviews describe the symptoms wherever groups run separate accounts: a patient who exists twice with half a history in each, reminders that name the wrong branch, reporting that only exists per site, and a receptionist with three tabs open to answer one question. In the UAE the usual reason for the split is the exchanges: a Dubai system that connects to NABIDH and a system in Abu Dhabi that connects to Malaffi, bought separately because each vendor only did one.

The alternative is a platform that treats the exchange and claims connection as a per-branch setting rather than a reason to buy twice.

The account structure

One account, with:

• Branches. Each with its own diaries, rooms, appointment types, opening hours and WhatsApp number.
• Roles. Group owner and group manager roles that see everything; branch manager roles that see their branch; doctors who work across branches with one diary; insurance coordinators per branch or for the group.
• One patient file per patient. Seen in Dubai and Sharjah, one file: Emirates ID and insurance details captured once, notes and documents from both branches, every WhatsApp thread, every invoice.
• One shared inbox. Every branch's WhatsApp, SMS and email in one place, each conversation tagged with its branch, assigned to whoever picks it up.

Reporting then falls out of the structure: utilisation, no-shows and revenue per doctor, per branch and for the group, without a spreadsheet.

Each branch connected to its own systems

This is the part that makes the single account possible. The platform connects each branch to the exchange and claims platform its emirate uses, as systems it connects to, scoped and built during onboarding:

Branch	Health information exchange	Claims platform
Dubai	NABIDH	eClaimLink / DHPO, insurers and TPAs
Abu Dhabi	Malaffi	Shafafiya, insurers and TPAs
Sharjah and the Northern Emirates	Riayati	Claims platform and payers as scoped

Patient and visit information recorded on the file is sent to the branch's exchange in the message set agreed on the scoping call; pre-approval requests and claims go to the branch's claims platform from the booking and the file; responses and remittance come back to the same record. The doctor at the Sharjah branch and the doctor at the Dubai branch work on the same patient file; the connections underneath differ, and the platform handles that per branch.

Each connection is named here as a system Capra connects to, built with you during onboarding, with every exchange logged.

Messaging across branches

Each branch keeps the WhatsApp number its patients already have saved. All of them run into the one shared inbox, tagged by branch, so a receptionist at any branch can see and answer any thread, with the patient file beside it. Reminders go out from the branch the appointment is at, with that branch's name and address, in the patient's language, with Confirm and Reschedule buttons. A patient who messages the Dubai number about a Sharjah appointment is routed to the right conversation rather than told to call another number.

Booking across branches

Online booking shows the patient the branch and doctor they want, with that branch's rules: a deposit for first aesthetics consultations in Abu Dhabi, no deposit for a follow-up in Dubai. Reception at any branch can book into any other. A doctor who works two days in Dubai and three in Sharjah keeps one diary across both, synced to the one Google or Outlook calendar they actually look at.

Reporting for the owner

The report the owner wants is the one that was impossible with three systems: every branch side by side. Utilisation per doctor and per room, no-show (DNA) rate per branch and appointment type, pre-approval turnaround per payer, revenue per doctor and per branch, response times on the inbox per branch. The patterns that show up are specific, a dental branch whose hygiene recalls run high, an aesthetics branch whose first visits need a deposit, and each fix is a setting on that branch alone.

Onboarding order

Multi-branch onboarding works branch by branch, with the quick wins first:

1. Account and roles. Branches, rooms, appointment types and roles set up for the whole group in one pass.
2. Patients imported and merged. Each branch's export is imported and patients who exist in more than one are matched and merged, with the merge checked with you before go-live.
3. Messaging and booking live. WhatsApp numbers, SMS, email, online booking and reminders live within a few days per branch.
4. Exchange and claims connections built. Each branch's connection scoped, built and tested against sample records, then switched on with monitoring, on the agreed plan.
5. Reporting and review. The first group report a month in, and the branch-level settings adjusted from it.

A named onboarding lead runs all five, in UAE hours, and stays the group's contact afterwards.

A worked example

Take an illustrative group: a polyclinic in Dubai with four doctors, a dental branch in Sharjah with two, and an aesthetics branch in Abu Dhabi with three practitioners. Before: three systems, a patient who moved from the Dubai polyclinic to the Abu Dhabi aesthetics branch had two files, the owner compiled a monthly spreadsheet from three exports, and the Sharjah receptionist answered WhatsApp from her own phone.

After: one account, one file per patient, three branch WhatsApp numbers in one inbox, the Dubai branch connected to NABIDH and eClaimLink / DHPO, the Abu Dhabi branch to Malaffi and Shafafiya, the Sharjah branch to Riayati, reminders in Arabic and English from the right branch, and a group report the owner opens rather than builds. This is an illustration of the setup, not a customer case.

Roles that keep the single account safe

One account for three branches raises the obvious question: who sees what? The answer is roles set per branch and per function, not a single admin login shared around.

• Group owner and group manager see every branch, every report and every setting.
• Branch manager sees their branch's diaries, patients, inbox and reports, and nothing from the other two.
• Doctor sees their own patients wherever those patients have been seen, and their own diary across branches.
• Reception books into any branch but sees clinical notes only where the role allows it.
• Insurance coordinator sees pre-approvals and claims for their branch or the group, without clinical detail they do not need.

Every view and every change is on the audit trail with the user, branch and time, so a question about who opened a file in Sharjah has an answer. The roles are configured during onboarding and changed by the group owner afterwards, without a support ticket.

What to look for

If your group spans emirates, the questions to ask any vendor are the ones above: one account or several, one patient file or one per branch, one inbox or one per number, which exchange and claims platform each branch connects to and who builds those connections, and whether reporting exists for the group. Capra's answers are on the clinic management software for Dubai page and the integrations page, and a demo will walk through the structure with your branches named.