Hospital Management Software in Saudi Arabia (2026): NPHIES, ZATCA and PDPL

The claim was clinically perfect. The patient had been admitted, operated on and discharged without a complication, the prior authorisation had been approved before surgery, and the bill was correct to the riyal. It came back rejected anyway, because the claim did not carry the authorisation reference and the follow-up visit had been raised under a different episode identifier. Two fields. Nobody on the ward had touched either of them; the software had simply never been asked to keep them together.

That is what buying hospital management software in Saudi Arabia is really about in 2026. Every insured encounter moves through NPHIES, every invoice through ZATCA's e-invoicing rules, and every record falls under the Personal Data Protection Law. The clinical modules matter, but they are table stakes. The system has to carry those three obligations through every step of the patient journey without a person holding them together by hand. This guide is for owners, CEOs, medical directors and finance heads of private hospitals, polyclinics and day-surgery centres in the Kingdom.

What does hospital management software need to do in Saudi Arabia?

It has to run the hospital — registration, clinical records, inpatient care, pharmacy, laboratory, radiology and billing — and carry three national obligations through all of it: insurance transactions through NPHIES, tax invoices under ZATCA's e-invoicing rules, and health data handled as sensitive personal data under the PDPL.

The failure mode is a system that does the clinical work well and treats the three obligations as exports at the end. That arrangement works until the month the claims backlog, the invoice queue and a data request arrive together. The useful question in any demo is where each obligation is enforced: at the point the data is created, or by somebody afterwards.

What is NPHIES, and why does it matter to a hospital?

NPHIES is the Kingdom's national platform for health insurance exchange services. Providers send eligibility checks, prior authorisation requests and claims to NPHIES, which validates each message and routes it to the insurer or third-party administrator, then carries the response back.

Messages are exchanged as HL7 FHIR message bundles, defined in the NPHIES implementation guide. That matters because a hospital system cannot fake its way through it: the platform validates structure, and a bundle with a missing or inconsistent element is rejected before an insurer ever sees it. The transactions a hospital system has to handle are these.

Eligibility

A check, before treatment, that the patient's coverage is active and what it covers. Done at registration, it is the cheapest rejection a hospital ever avoids.

Prior authorisation

A request for the insurer's approval before a service is delivered, routed through NPHIES, adjudicated by the insurer and returned as an approval, a denial, a partial approval or a request for more information. Institutional authorisations cover hospital services such as admissions and surgery.

Claims

The claim for the service delivered. Two rules from the implementation guide catch hospitals out: if an authorisation was obtained, its details must be on the claim, and all claims for the same patient episode must carry the same episode identifier. Newborns, who usually have no coverage of their own for roughly the first month, are billed on their own patient record under the mother's coverage.

Status, polling and cancellation

Supporting transactions that let a provider check where a submission stands, collect asynchronous responses and cancel a request raised in error. A system that cannot do these leaves staff refreshing a portal instead.

The test of an NPHIES integration is not whether it can send a claim. It is whether the authorisation, the episode and the claim are linked by the system, so that nobody has to remember to link them.

Which medical coding does Saudi Arabia use for claims?

Insurance claims in the Kingdom use ICD-10-AM for diagnoses and the Saudi Billing System (SBS) for procedures and services, with AR-DRG grouping for inpatient episodes where the payer settles on DRG. The coding sets are Australian-derived, which is why software built around ICD-10-CM and CPT for the American or Emirati market needs real work before it is ready for Saudi claims.

Ask a vendor which version of each code set they hold, who maintains the mapping, and how quickly an update reaches your coders. Coding is where a large share of avoidable rejections begin, the same lesson our guide to first-pass claim rates draws from Indian hospitals.

What does ZATCA e-invoicing require of hospital billing?

Every tax invoice must be generated electronically in ZATCA's format and, under Phase 2, integrated with ZATCA's FATOORA platform. Invoices are produced as UBL 2.1 XML with a cryptographic stamp, a unique identifier and a QR code, and the billing system itself — not a person re-keying into a portal — has to produce them.

Phase 1, generation, began on 4 December 2021. Phase 2, integration, has been rolled out in waves since 1 January 2023, each wave defined by revenue: wave 23 brought in taxpayers above SAR 750,000 by 31 March 2026, and wave 24 those above SAR 375,000 by 30 June 2026, with later waves reaching smaller taxpayers. ZATCA notifies each taxpayer of its date in advance, and that notice is the deadline to plan against.

Two invoice types matter to a hospital:

• Standard tax invoices, typically issued to insurers and corporate clients, which must be cleared by ZATCA before they are issued.
• Simplified tax invoices, typically issued to self-paying patients, which are reported to ZATCA within 24 hours of issue.

VAT is charged at 15%, and the state bears the VAT on certain private healthcare for Saudi citizens, so the billing engine has to know which rule applies to which patient and service. Confirm the treatment of your own services with your tax adviser.

Does health data have to stay in Saudi Arabia?

The PDPL treats health data as sensitive personal data and restricts transfers outside the Kingdom, so in practice most hospitals host their systems in Saudi Arabia. The law has been enforced since 14 September 2024, when the one-year grace period ended.

The obligations that reach software are concrete: a lawful basis for each processing purpose, access limited to what each role needs, breach notification to SDAIA within 72 hours of becoming aware of a notifiable breach, and fines that can reach SAR 5 million. SDAIA has been issuing enforcement decisions, so this is no longer a law on paper. Alongside it, the National Cybersecurity Authority's controls and the requirements of your own regulator shape where data may sit and who may reach it.

For the purchase, that means in-Kingdom hosting for production data and backups, an agreed position on how and from where vendor support accesses the system, and an access log that records who viewed a record, not only who changed it — the subject of our article on what a good audit log records. This is a summary for buyers, not legal advice; confirm the position for your facility with counsel.

Does hospital software in Saudi Arabia need Arabic?

Yes. Tax invoices must be issued in Arabic, and may carry a second language alongside it, and patient-facing documents such as consent forms, discharge summaries and prescriptions are routinely expected in Arabic as well.

Bilingual output is a test, not a checkbox. Arabic runs right to left, patient names need to be held in both scripts, and a document that mixes the two must still print cleanly and read correctly on the QR-coded invoice. Bring your own documents to the demo and ask to see them produced in both languages.

What does CBAHI accreditation ask of the software?

CBAHI, the Saudi Central Board for Accreditation of Healthcare Institutions, assesses hospitals against national standards on patient identification, medication management, infection control, the medical record and leadership, and every one of those leaves an evidence trail that a surveyor can ask to see.

Software does not accredit a hospital. It decides whether that evidence is a by-product of daily work or a scramble before the survey. Look for positive patient identification at every step, a medication administration record kept at the bedside, record-completion tracking, and reports that show compliance over time rather than on the day. Our article on walking into an accreditation audit was written for India's NABH, but its point — that audit readiness is a property of the workflow — applies to any national standard.

Which modules does a Saudi hospital need?

The full clinical core, plus the pieces that the Kingdom's payers, tax authority and regulators make non-negotiable.

• Registration with national ID or Iqama capture, insurance details and an NPHIES eligibility check.
• OPD and EMR with coded diagnoses and structured orders, because the claim is built from the record.
• Inpatient care, beds and the operation theatre, with authorisation status visible to the people delivering the care.
• Pharmacy with batch and expiry control and a controlled-medicines register.
• Laboratory and radiology, with results returning to the chart and charges raised automatically.
• Insurance and claims on NPHIES: eligibility, authorisation, claims, status and remittance reconciliation.
• Billing that produces ZATCA-compliant standard and simplified invoices with the right VAT rule per line.
• Workforce and credentialing, with licence expiry tracked for every clinician — see credential expiry.
• Inventory and purchasing across stores and branches.

How much does hospital management software cost in Saudi Arabia?

Like everywhere, the structure of the price matters more than its headline. Vendors quote per bed, per user, per module or per facility; the lines that move the total in the Kingdom are the NPHIES integration and its certification effort, ZATCA e-invoicing integration, in-Kingdom hosting with backups and disaster recovery, Arabic configuration, and the support model.

Put five years of all of it side by side, at today's size and at the size you plan to be in year three. Our guide to affordable hospital management software has a worksheet for exactly this comparison; it was written for India, but the lines are the same.

What is the cheapest hospital management software in Saudi Arabia?

The cheapest system to buy is usually a clinic-grade product, or a general ERP with healthcare screens bolted on. The cheapest system to run is the one that gets NPHIES claims paid on first submission, keeps ZATCA invoicing automatic, and does not need separate products stitched together for the pharmacy, the laboratory and the claims desk.

In a market where nearly every private patient is insured, a few points of rejection rate are worth more than the gap between a cheap licence and a complete suite. Ask what each system will cost over five years, with every module and integration you need, and what evidence the vendor has about its rejection rate at live hospitals.

What should you ask a hospital software vendor in a Saudi demo?

Ten questions, in writing, before the demo.

• Which NPHIES transactions do you run in production today, and at which hospitals?
• Show an authorisation, its claim and a follow-up visit linked under one episode, end to end.
• Which ICD-10-AM, SBS and AR-DRG versions do you hold, and who keeps them current?
• Show a standard invoice cleared and a simplified invoice reported to ZATCA.
• Where will production data, backups and disaster-recovery copies be hosted?
• From which country will your support team access our system?
• How do you support a PDPL access or breach-response request?
• Print an invoice, a consent form and a discharge summary in Arabic and English.
• Can we speak to a live customer of similar size in the Kingdom?
• What does it cost to export all our data, and in what format, when we leave?

If you are replacing an existing system, our guide to switching hospital software covers the cutover, and one platform or best-of-breed covers why the number of systems you run matters more than any single feature.

Where Kōami fits

Kōami is built to give hospitals a premium, complete suite at an affordable price. Kōami Hospital runs registration, OPD and EMR, inpatient care, the operation theatre, pharmacy, laboratory, radiology and billing on one patient record, with ICD-coded diagnoses, structured orders, a tariff and package engine for insurers and corporates, role-based access and an audit log of every view and edit. Because authorisation, episode and bill sit on the same record, the link a claim depends on is held by the system rather than by a member of staff. Workforce, Inventory and PACS join the same platform when you need them.

The pricing is structural rather than a discount: you pay only for the modules you switch on, hospital deployments are typically priced per bed with unlimited users, and onboarding, data migration support and training are included in hospital plans. Enterprise plans support cloud, hybrid and on-premise deployment, which is how a hospital in the Kingdom keeps its data in the Kingdom.

Saudi-specific work — NPHIES transactions, ZATCA e-invoicing integration, Saudi code sets and Arabic documents — is scoped for your facility during evaluation, and we will confirm in writing what is in place before you sign, the same standard this guide asks of every vendor. See how Kōami pricing is structured, then book a demo with your payer mix and your current quotation. Groups working across the Gulf may also want our guides for the UAE and Kuwait.