The two acronyms come up in almost every conversation about Saudi medical insurance, and they are frequently used as if they were the same thing. They are not. Understanding who does what is the first step to handling claims correctly — because each one sets rules or checks data in a different place.
CCHI is the regulator
CCHI — the Council of Cooperative Health Insurance — is the regulator for cooperative health insurance in Saudi Arabia. Its role is to set the rules of the market: what insurers may and may not do, what providers must comply with, and how the system is overseen. When you read about compliance requirements, classification, or the framework insurers operate under, that is CCHI's territory.
CCHI does not process your claim. It defines the environment in which claims are made and adjudicated.
NPHIES is the exchange
NPHIES — the National Platform for Health Insurance Exchange Services — is the national platform that actually carries insurance transactions between providers, insurers and regulators. Eligibility checks, prior authorizations, claim submission and remittance advice all move through it.
NPHIES is built on HL7 FHIR. In practice, that means data must be structured the expected way. A claim that is clinically reasonable can still fail if it is not packaged in the format the platform expects.
How they fit together
A simple way to hold the two apart:
- CCHI sets the rules — the regulatory framework for cooperative health insurance.
- NPHIES moves the data — the exchange through which those rules are applied to real transactions.
CCHI can introduce or change requirements; NPHIES is the mechanism through which providers and payers then carry them out. When a rule changes, it often shows up first as a change in what NPHIES accepts or rejects.
Why the distinction matters operationally
When a claim goes wrong, the first question is which layer failed:
- If the failure is about format, schema, identifiers, or eligibility data, it is a platform-level (NPHIES) issue. These are the technical rejections that careful data capture and pre-submission validation prevent.
- If the failure is about coverage, medical necessity, or what is contractually payable, it is a regulatory/contract issue. These are the medical rejections and denials that require clinical justification, correct coding, and sometimes a discussion with the payer.
Treating every rejection as the same problem — and the same fix — is expensive. Separating the two tells you whether to fix your data, your coding, or your contract.
Practical takeaways
- Keep your registration and eligibility data clean; it is the foundation both systems rely on.
- Code with the correct ICD-10-AM diagnoses and ACHI procedures so the clinical picture survives the exchange.
- Know your contract — what is covered and at what price — not just the platform's technical rules.
- Track rejections by cause, so technical and medical problems are worked by the right people.
How MedSure helps
We help facilities where these distinctions are getting lost in day-to-day operations. Our medical insurance consulting covers RCM optimization, rejection analysis and compliance, while training brings the concepts to your team. For definitions of the terms used here, see the glossary; for common questions, see the FAQ.
Contact MedSure to review where your claims are failing — and at which layer.