NPHIES · Saudi Arabia
Claims that leave the chart already speaking NPHIES.
The Saudi national rail is built into the record rather than bolted onto it. Eligibility, pre-authorisation, claim submission and remittance are all assembled as FHIR R4 bundles from the encounter your clinician already documented.
- FHIR R4 bundles
- Eligibility and pre-auth
- Per-line adjudication
- Remittance import
What NPHIES is
The national exchange every Saudi claim travels through.
NPHIES is the Saudi Arabian national platform for health insurance exchange. Providers and payers meet on it to confirm a patient's coverage, ask for approval before an expensive procedure, file the claim afterwards, and settle what is owed. It is FHIR R4-based: every message is a bundle of standard resources rather than a proprietary file format.
That matters for a clinic because it removes the translation layer. The Clinic builds a CoverageEligibilityRequest, a Claim with use=preauthorization, or a Claim with use=claim directly from the patient, coverage and encounter data already in the chart — the same Patient and Coverage resources, carrying the national identifier under the NPHIES identifier system, in one bundle.
Nothing is retyped into a payer portal and nothing is exported to a spreadsheet in between. The rail is resolved per clinic from the jurisdiction set in Regional Settings, so a Saudi clinic gets NPHIES automatically and a clinic anywhere else never sees it.
Eligibility and pre-authorisation
Confirm coverage and get approval before the chair is occupied.
An eligibility request is assembled as a CoverageEligibilityRequest bundle — purpose validation and benefits — alongside the Patient and Coverage resources it references, with the patient's national ID carried under the NPHIES identifier system. Pre-authorisation reuses the same builder: it is a FHIR Claim with use set to preauthorization, so an approval request and the claim that follows it can never drift apart.
- CoverageEligibilityRequest built from the patient record, not retyped
- Pre-authorisation is a Claim with use=preauthorization, sharing the claim builder
- National ID carried under the NPHIES identifier system
- Structure checks run over a sample bundle before you go live
Claim submission
A payer answer you can act on, line by line.
Claims go out as FHIR R4 Claim bundles with priced items. When NPHIES answers with a ClaimResponse, its per-item decision is staged against your claim — allowed, payable, patient responsibility, denial code and reason for each line. That staged adjudication is treated as an opinion about money, never as a deposit: settlement only happens when the remittance arrives.
- Priced FHIR Claim items built from the invoice lines
- Per-line allowed, payable, patient-responsibility and denial detail staged
- A refused claim comes back carrying the payer's own reasons
- A line with no procedure code cannot be priced — it is named in a warning, never dropped in silence
Delivery evidence
A timeout is not a failure, and it is never a second claim.
Every transmission is classified rather than guessed at. A 2xx carrying a readable ClaimResponse is a filing. An OperationOutcome is a refusal, with the payer's reasons attached. A 5xx, or a request that runs past the thirty-second window, is neither: the payer may have stored the claim before failing to answer, so the attempt is recorded as unknown delivery and resubmission is blocked until a person confirms with the payer.
- Transmitted, rejected, unknown-delivery and built-only are four different outcomes
- Unknown delivery blocks a retry, so a claim cannot be filed twice
- The exact bundle that was sent is stored as evidence beside the answer
- Sandbox transmissions are resolved as such and never look like real filings
NPHIES coverage in the gateway
- FHIR R4
- message format
- 4
- transaction types built
- 30s
- payer response window
- 0
- blind retries after a timeout
Before your first live claim
What a Saudi clinic has to configure.
The rail is code; the enrolment is yours. These are the fields the platform needs before it can build and send a real NPHIES message, all entered in Settings → Integrations → Insurance rails.
- 01
Jurisdiction
Set the clinic's jurisdiction to Saudi Arabia in Regional Settings. It is required at clinic creation and is what selects NPHIES as the claims rail for everything the clinic files.
- 02
Endpoint and environment
Each rail configuration belongs to one environment. Point the sandbox configuration at your NPHIES test endpoint first; production is a separate row with its own endpoint and its own credentials.
- 03
API credentials
The bearer key NPHIES issues to your organisation. Rail credentials are encrypted per clinic, are never placed in an environment file, and are never shown back to the browser.
- 04
Provider identifier
Your NPHIES organisation identifier. It is referenced as the provider on every eligibility request, pre-authorisation and claim the clinic builds.
- 05
Payer identifiers
The insurers you are contracted with. The first configured payer is referenced as the insurer on a request when the claim itself does not name one.
- 06
Readiness check
Run the rail readiness report before going live. It builds a sample eligibility, pre-authorisation and claim bundle and verifies each one carries the required resources and references — a gap is reported, never hidden.
The honest edges
What the NPHIES rail does not do yet.
Naming this is cheaper than letting you find it during enrolment. These are real gaps in the current gateway, not future tense dressed up as present.
Eligibility answers are not decomposed
The request is built, validated and transmitted, and the payer's response is stored in full against the check. The benefit detail is not yet broken out into structured coverage fields for you.
No claim status inquiry
There is no poll for asking NPHIES where a filed claim stands. Status reaches you through the payer's answer at submission and through the remittance.
Terminology maps are seeded, not complete
Coding is checked before a message is built, and an unmapped code is raised loudly rather than transmitted. Expect to extend the code maps with your own catalogue during enrolment.
Sandbox first, always
Production credentials are a separate configuration. Nothing about a sandbox transmission is presented as a real filing, and it never settles money.
NPHIES questions
What clinics ask before they enrol.
Is The Clinic NPHIES integrated?
The NPHIES gateway is built into the platform: it constructs FHIR R4 eligibility, pre-authorisation and claim bundles from the clinic record and posts them to the endpoint you configure. What it cannot do is enrol you — the endpoint, the API key and your provider identifier come from NPHIES, and until they are entered the platform builds and validates messages without transmitting them.
Which NPHIES transactions can the platform send?
Coverage eligibility requests, pre-authorisation requests (a FHIR Claim with use=preauthorization) and claim submissions (a Claim with use=claim). Remittance runs in the other direction: a PaymentReconciliation bundle with its ClaimResponse resources is parsed into per-line payment, adjustment and denial detail and imported against the original claims.
What happens if NPHIES does not answer?
The request has a thirty-second window. If it expires, or the payer returns a 5xx, delivery is genuinely unknown — the claim may have been stored before the failure. That attempt is recorded as unknown delivery and it blocks resubmission until someone confirms with the payer, because a blind retry is how a clinic files the same claim twice.
Does a payer answer post money to the ledger?
No. A ClaimResponse returned at submission is staged as a per-line adjudication — an opinion about money. Cash moves only through the remittance path, when the payment actually arrives, so an answer that later changes cannot leave a phantom deposit behind.
Where are the NPHIES credentials stored?
Encrypted, per clinic, against that clinic's rail configuration. They are entered in Settings → Integrations → Insurance rails, are never placed in an environment file, and the readiness report names which credential keys are set without echoing their values.
Can one platform serve clinics in Saudi Arabia and elsewhere?
Yes. The rail is resolved per clinic from its jurisdiction, so a Saudi branch files through NPHIES while a Dubai branch files through eClaimLink and an Ontario branch builds an OHIP batch — with separate credentials and no cross-tenant visibility.
Related
The rest of the interoperability surface.
- Standards and exchanges
FHIR R4, NABIDH over HL7 v2.5, and DICOMweb imaging in one place.
- eClaimLink (Dubai DHPO)
How a Dubai facility files a Claim.Submission through the DHPO.
- OHIP (Ontario MCEDT)
How an Ontario clinic builds and submits an MCEDT claims batch.
Ready to try The Clinic
See it run your clinic in 30 minutes.
Book a personalized demo. We'll use your clinic's real workflows — not a generic walkthrough.
No credit card. No slides. 30 minutes.