Claims
The billing department gets its own system.
CCMS is for pharmacy groups whose claims are handled by a back office, not by whoever is on shift. Every branch's submissions, remittances and denials arrive in one queue, worked by the people whose job it actually is — while the pharmacist gets on with dispensing.
[00]
branches on one queue
1M+
claims processed
1 day
to onboard*
* Hardware and network ready on the day. Connecting the group's payer mailboxes is scoped separately.
Approved and connected
The gateways your billing team submits through.
LOGO
Shafafiya
LOGO
DHPO
LOGO
NPHIES
LOGO
eRx
What it does
One team, every branch's insurer money.
Above a certain size, claims stop being a pharmacist's job. A back office does it properly — but only if it can see every branch at once, in one queue, with the denial reasons grouped. That is what CCMS is.
One queue for the whole group
Every branch's submissions and denials in a single work list, assignable to the billing team by branch, payer or age.
Central submission
Claims from every site go out through the group's Shafafiya, DHPO and NPHIES mailboxes on one schedule, rather than branch by branch.
Remittance reconciliation
Payments matched against submissions per branch and per payer, so you can see which site is being paid and which is quietly not.
Denial management
Denials grouped by reason so the pattern is visible: the payer, the branch, or the code that keeps costing you money every month.
Group reporting
Claim value, rejection rate, recovery rate and days-to-payment, by branch, insurer and month.
Access by role and site
The central team sees everything, a branch manager sees only their own site, and a full activity log sits behind both.
How the back office works
How the claim actually travels.
STEP 01
The branch dispenses
The pharmacist takes the approval and hands the medicine over. That is the end of their involvement — the claim leaves the counter and lands in the central queue.
STEP 02
The back office submits
The billing team works one list across every branch, checks the coding, and submits to Shafafiya, DHPO or NPHIES on the group's own schedule.
STEP 03
The money is matched
Remittances download and reconcile against submissions, per branch and per payer. What was paid, what was short-paid and what was ignored are three different columns.
STEP 04
Denials are worked, not written off
Rejections are grouped by reason and assigned. The team corrects and resubmits — and the pattern report tells you which branch or code to fix at source.
Inside the product
Modules, in the order the billing team meets them.
Three screens carry the department. Each one replaces a spreadsheet that somebody currently owns.
The claims queue
Where the day's work lives: every branch's claims in one list, filtered by payer, branch, age or value, and assignable to a named person. A claim in a queue with an owner is a claim that gets chased.
All branches Assignment
Submission and remittance
Where the money moves: batch submission to the payer mailboxes, remittance download, and reconciliation per branch and per payer. Short-payment is treated as a separate outcome from non-payment, because it is.
Shafafiya · DHPO NPHIES
Denials and analysis
Where the leak is found: denials grouped by reason, correction and resubmission from the same screen, and reporting on rejection and recovery rate by branch, payer and code.
Grouped by reason Recovery rate
Proof
One customer, one number, one quote.
[Customer quote to come — two sentences from a named operator at a named site.]
[Name Surname]
[Role · Organisation]
[00%]
Outcome measured
[00m]
Outcome measured
Deployment
One day for a group already running EzPOS — we load the branch structure and user roles, and your billing team works its first queue the same week. Nothing new is installed at the branch: each site's claims are pointed at the group's central claims database instead of the local one. Connecting the payer mailboxes runs on the authority's timeline, and we handle that end of it.
Works with
Pairs with the rest of the suite.
Each of these does its own job. Most customers add the next one once the first has paid for itself.
EzPOS
Every branch dispenses on EzPOS; the claims it raises land in the central queue automatically.
EzRx
The claims engine at the counter. CCMS is what you add when one person per branch stops being the right way to run it.
e-Inventory
The same group from the other side: e-Inventory keeps the shelves right, CCMS keeps the insurer payments right.
AMS
Insurer receipts reconcile against group receivables, so the billing team and the ledger agree.
Questions
The four things groups ask first.
What it changes, what it installs, where the data sits, and who sees what.
How is this different from EzRx?
EzRx puts claims in the hands of the pharmacist at the counter, which is right for a single pharmacy. CCMS puts them in the hands of a back office that handles every branch. Groups above roughly [10] sites usually need the second one.
Do we have to install something new at every branch?
No, and that is why it goes in so quickly. Each branch already raises claims where it dispenses; CCMS points those claims at one central claims database for the group instead of the one on the branch's own server. The pharmacist's screen does not change.
Where does the central claims database live?
Either on your own server, or in cloud we host and manage — most groups now choose the second, because it means the back office reaches every branch's claims without a VPN into each pharmacy. Both are offered; the choice is yours to make on your own policy.
Can a branch manager see their own claims?
Yes, and only their own. Access is scoped by site, so a branch sees its own rejection rate without seeing the rest of the group's.
See it on your own workflow.
Tell us which authority licenses you and what you run today. We'll configure the walkthrough for your market — thirty minutes, no slide deck.
A specialist replies within one working day
Onboarded in one day once you are ready
We review your data migration before you commit