In this article
- What NPHIES is
- Who the checklist is for
- Organization and facility
- Provider information and documents
- Technical integration
- Eligibility verification
- Pre-authorization
- Claims submission
- Testing and error handling
- Data quality and security
- Go-live readiness
- Monitoring and maintenance
- Common mistakes
- The full checklist
- FAQ
Key takeaways
- NPHIES is the national platform Saudi providers and insurers use to exchange eligibility, pre-authorization, claim and payment messages in HL7 FHIR R4.
- Registration needs four things: the NPHIES Academy certificate, your facility’s NPHIES ID, a stamped authorized person form and a copy of that person’s ID.
- You can connect through a system whose vendor has already integrated, or build a direct integration. The checklist applies to both; the amount of work differs.
- Most rejected claims trace back to data: identifiers, coverage details, codes and authorization references. Fix those before testing, not after go-live.
- Go-live is a starting point. The implementation guide and code sets are versioned, so someone has to own the connection afterwards.
Most providers come to NPHIES with one practical question: what exactly do we have to get ready, and in what order?
The official material answers it, but across several places: an Academy course, a registration guide, a unified portal and a technical implementation guide written for developers. This NPHIES checklist brings those together for the people who share the work in a hospital, clinic group, pharmacy or lab: operations, IT, billing and revenue cycle.
We have been careful about one thing. A lot of NPHIES content presents advice as if it were regulation. Here, every item carries one of three labels so you can tell them apart.
Stated in official NPHIES or Council of Health Insurance material.
Not mandated, but most go-lives depend on it.
General groundwork that makes the rest easier.
Requirements varyWhat applies to you depends on your provider type, the insurers you work with, and whether you connect directly or through a vendor’s system. Treat this as a working checklist, and confirm anything binding with CHI or the NPHIES onboarding team.
What NPHIES is and why it matters
NPHIES, the National Platform for Health and Insurance Exchange Services, is Saudi Arabia’s national platform for health insurance transactions. Providers and insurers exchange eligibility checks, pre-authorizations, claims and payment information through it in one standard format, HL7 FHIR R4, instead of through separate links to each insurer.
The official material writes the name in lower case, “nphies”. The insurance services are overseen by the Council of Health Insurance (CHI), and the technical rules are published in an implementation guide on the NPHIES portal.
For a provider, the practical meaning is simple. If you treat insured patients, the answer to “is this patient covered?”, “is this service approved?” and “has this claim been paid?” now travels through NPHIES. A connection that works well shortens the time between treating a patient and being paid. A connection that works badly shows up as rejected claims and staff re-keying data.
| Transaction | What it does | How the answer arrives |
|---|---|---|
| Eligibility check | Confirms whether a patient’s coverage is in force and what it includes | Real time |
| Prior authorization | Requests the insurer’s approval before a service is delivered | Real time or deferred |
| Claim submission | Bills the insurer for services already delivered | Real time or deferred |
| Batch claims | Submits a group of claims together | Deferred |
| Payment notice and reconciliation | Tells the provider what was paid and against which claims | See the guide |
| Communication | Carries requests for, and submissions of, supporting information | See the guide |
| Supporting messages | Cancellation, status check, polling and error notices | Cancellation is real time |
Source: NPHIES Healthcare Financial Services implementation guide. “Deferred” means the full answer comes later and your system collects it.
If you want the commercial and engineering detail behind these flows, our NPHIES integration services page covers how we build them. This article stays with the checklist.
Who should use this checklist
NPHIES readiness is shared work. It tends to stall when one team assumes another has it covered, so it helps to be clear about who owns which part.
Operations and administration
Registration, the authorized person, licences, payer contracts and the go-live decision.
IT and system owners
The connection itself: the HIS or billing system, the vendor, message handling, security and monitoring.
Billing, coding and revenue cycle
Code mapping, claim quality, rejections, resubmissions and payment reconciliation.
Front desk and approvals staff
Capturing patient and policy details correctly, running eligibility checks and managing authorization requests.
It is written for hospitals, polyclinics, dental and optical centres, pharmacies, laboratories and the software vendors that serve them. A single-site clinic using an already integrated system will move through several sections quickly. A hospital group with its own HIS should expect to use all of them.
Organizational and facility readiness
Before any technical work, NPHIES onboarding asks you to name people and complete training. These steps are short, but nothing else can start until they are done.
Name an NPHIES championRequired
The Academy describes the champion as the person who leads onboarding inside your organization: proactive, comfortable in Arabic and English, and familiar with the insurance side of the business. One per organization is the norm.
Name an authorized personRequired
A senior representative, such as the CEO or a deputy general manager, who registers the facility on the portal and accepts the terms of use. There is one per organization, and the same person can also be the champion.
Complete the NPHIES Academy courseRequired
The course is free and takes about two hours. The certificate it issues is one of the documents you need to join. If each branch has its own champion, each of them takes the course.
Agree who owns whatRecommended
Decide who owns registration, the technical connection, code mapping and day-to-day claims. Write it down. Most delays we see come from unowned tasks, not hard ones.
Define the scopePreparation
List the facilities, departments, insurers and claim types you will go live with first. A phased scope is easier to test well than everything at once.
Provider information and required documentation
NPHIES portal registration is where most providers first get stuck, usually over a missing identifier or an unstamped form. The Academy lists four requirements for joining.
NPHIES Academy certificate
Issued automatically when the champion finishes the mandatory lessons and the course evaluation.
Your facility’s NPHIES ID
The 14-digit NHIC identifier for the facility. The Academy directs providers to obtain it through the Seha platform.
Authorized person form, stamped
The form is provided with the registration lesson and must be stamped by the Chamber of Commerce before you upload it.
Copy of the authorized person’s ID
Uploaded with the stamped form on the facility information page of the unified portal.
Around those four, a few checks save a lot of back and forth:
Make identifiers match everywhereRecommended
Your CHI accreditation number, facility licence and NPHIES ID should be identical in the portal, your HIS and your payer contracts. A stray space or an old number is enough to fail a check.
Check practitioner recordsRecommended
Claims reference the treating practitioner. Make sure licence numbers and specialties in your system are current and complete.
Keep one registration folderPreparation
Store certificates, forms, portal accounts and payer contacts in one shared place, so the process does not depend on one person’s inbox.
Registration questions go to the NPHIES onboarding team, whose contact details are published on the Academy site.
Technical integration and system readiness
The first technical decision is how you connect. NPHIES runs onboarding for system vendors as well as providers, which is why many providers connect through software that is already integrated.
| Through an integrated system | Direct integration | |
|---|---|---|
| What it is | Your HIS, practice system or billing product already exchanges NPHIES messages | Your own system, or a layer beside it, is built to exchange them |
| Your work | Registration, configuration, code mapping, data clean-up, training | All of that, plus development, testing and upkeep of the connection |
| Suits | Clinics and centres on standard software | Hospitals and groups with a custom or heavily adapted HIS |
| Watch for | How quickly the vendor follows guide updates, and what you can see when a message fails | Who maintains it after go-live, and how updates are tested |
Whichever route you take, the same technical requirements sit underneath.
Build to the current implementation guideRequired
Messages follow HL7 FHIR R4.0.1 and the NPHIES profiles. Each exchange is a FHIR message bundle with a required message header, sent to the platform’s process-message operation. If a vendor does this for you, ask which guide version they support.
Use the national code setsRequired
Diagnoses in ICD-10-AM, services billed with the Saudi Billing System, and the billing value sets defined for each claim type. Local or legacy codes have to be mapped before they reach a message.
Handle deferred answersRequired
Eligibility is answered in real time, but pre-authorizations and claims can be deferred. Your system has to poll for waiting messages and match each answer to its original request.
Keep every identifierRecommended
Store the request, response and bundle identifiers for each message. Without them, you cannot trace a rejection or answer a payer query.
Plan for the unhappy pathRecommended
Timeouts, a payer being offline, duplicate submissions and cancelled requests all happen. Decide what staff see and do in each case.
If FHIR is new to your team, our guides to HL7 and FHIR and FHIR-based data exchange explain the building blocks. For a custom build, see our FHIR integration services.
Insurance eligibility verification
An NPHIES eligibility check asks the insurer one question: is this patient’s coverage in force, and what does it include? It is the cheapest point in the whole cycle to catch a problem, because nothing has been delivered or billed yet.
Capture identity exactlyRequired
Record the patient’s identifier and type exactly as shown on the document, along with the insurer and policy or membership details. Most failed checks are a typing or matching problem.
Check before the serviceRecommended
Run eligibility at booking or registration rather than at billing. Decide who sees the result and what happens when coverage is not confirmed.
Read the whole answerRecommended
A response can show coverage in force and still exclude the planned service or carry limits. Make benefits and limits visible to the staff who need them.
Keep the responseRecommended
Store the eligibility response with the visit. It is your record of what the insurer said on the day.
Have a fallbackPreparation
Agree what the front desk does if a check cannot be completed, so patients are not left waiting on a system.
How strictly eligibility is tied to later steps differs by insurer, so confirm each payer’s expectations. For high volumes, eligibility and denial automation can run these checks in the background.
Pre-authorization workflows
Pre-authorization, called prior authorization in the implementation guide, asks the insurer to approve a service before it is delivered. NPHIES defines separate authorization profiles for institutional, professional, pharmacy, dental and vision services. If the concept is new, start with our explainer on what prior authorization is.
Know what needs approvalRecommended
Which services need pre-authorization is set by each insurer’s policies and your contracts, not by NPHIES itself. Keep that list per payer and review it when contracts change.
Send the right profileRequired
Use the authorization profile that matches the service type, with the diagnosis and service codes the guide expects.
Attach supporting information earlyRecommended
Insurers can ask for more information through communication messages. Requests that arrive complete are answered faster.
Work from one queueRecommended
Pending, queried, approved and rejected requests should sit in one worklist with an owner, not in individual inboxes.
Carry the reference forwardRecommended
The approval reference has to appear on the claim. Make that automatic so nobody copies it by hand.
Track validityPreparation
Approvals can carry limits on dates or quantities. Surface them to scheduling so services are delivered inside them.
Claims submission and validation
A claim is the end of a chain. If eligibility, authorization and coding were handled well, submitting NPHIES claims is mostly routine. If they were not, this is where it shows.
- 1EligibilityCoverage confirmed
- 2Pre-authorizationApproval reference
- 3Care and codingICD-10-AM, billing codes
- 4ClaimValidated, then sent
- 5AdjudicationInsurer’s decision
- 6PaymentNotice and reconciliation
Use the correct claim typeRequired
The guide defines institutional, professional, pharmacy, dental and vision claims, each with its own profile and billing value set. A service sent under the wrong type will not validate.
Meet the profile’s required fieldsRequired
Each profile marks elements as required. Missing or badly formatted values are returned as validation errors rather than reaching adjudication.
Validate before you sendRecommended
Check identifiers, required fields, code validity and authorization references inside your own system first. A rejection you prevent costs far less than one you rework.
Follow each claim to the endRecommended
Track every claim through submission, acknowledgement, adjudication and payment, including deferred responses that arrive later.
Reconcile paymentsRecommended
Match payment notices and reconciliation messages to the claims they cover, and investigate differences while they are fresh.
Coding quality deserves its own attention. Our guide to medical coding covers the fundamentals, and revenue cycle management explains where claims sit in the wider process.
Testing, error handling and troubleshooting
CHI describes an activation stage: a set of procedures and tests that confirms a connection works before it is used in production. Providers on a vendor’s system inherit much of that testing. A direct integration has to pass it in its own right.
No real patient data in testingThe implementation guide states that implementers must not send real patient or confidential information through the testing environments. Use dummy data and mask anything that could identify a person.
How NPHIES reports errors
The guide separates two kinds of failure. If a message cannot be read or is structurally invalid, it is refused with an error outcome. If it can be read but the content breaks a rule, you receive a response listing rule codes. Those codes start with a two-letter prefix:
BVBusiness and validationThe content breaks a business or validation rule.DTData typeA value is in the wrong format.IBBindingA code is not from the expected code system.ICCardinalityA required element is missing, or repeated too often.Correct and resubmitRequired
The guide’s expectation is plain: errors are reported so they can be corrected and the message sent again. Your system needs a clear route for that.
Test every scenario you will useRecommended
Cover each claim type and insurer in scope, plus cancellations, deferred responses, queries for information and an insurer being offline.
Translate codes for staffRecommended
Show billing staff what went wrong in plain language, with the field to fix, rather than a raw rule code.
Log every failure by causeRecommended
Record each error with its code, claim type and insurer. Patterns appear within days and point to the fix.
Rehearse the dayPreparation
Run a full day of realistic volume through testing before cutover, with the people who will do the work.
Data quality, security and compliance
NPHIES validates what you send, so weak master data turns directly into rejected messages. Security matters for a different reason: every message carries personal health information.
Data quality
Clean patient recordsRecommended
Remove duplicates and correct identifiers, names and dates of birth. Matching against the insurer’s record depends on them.
Version your code mappingRecommended
Keep the mapping from internal service codes to national codes under change control, with an owner and effective dates.
Maintain the price and service masterRecommended
Services in your billing master should each resolve to a valid billing code for the right claim type.
Security and applicable regulation
Accept and follow the platform termsRequired
The authorized person accepts the NPHIES terms of use at registration. Make sure the people operating the connection know what was agreed.
Control and review accessRecommended
Give portal and system access by role, remove it when people leave, and review it on a schedule.
Protect credentials and keysRecommended
Store connection credentials securely, limit who can reach them and rotate them under a documented process.
Keep audit logsRecommended
Log who sent, viewed and changed what, and retain logs in line with your policy.
Check which laws apply to youPreparation
Health data in Saudi Arabia falls under the Personal Data Protection Law, and some organizations are also subject to National Cybersecurity Authority controls. Which obligations apply depends on your organization, so confirm them with your compliance or legal team.
This article is practical guidance, not legal advice. If you operate in other Gulf markets, similar thinking applies to NABIDH in Dubai and Malaffi in Abu Dhabi.
Go-live readiness
Go-live should be a decision someone makes against agreed conditions, not a date that simply arrives. These are the gates we suggest.
Activation completeRequired
The tests required for your integration are passed and production access is confirmed for the facilities in scope.
Open issues reviewedRecommended
Every known defect has an owner and a decision: fixed, accepted with a workaround, or blocking.
Staff trained on the real screensRecommended
Front desk, approvals, coding and billing staff have practised their own tasks, including what to do when something fails.
Cutover plan agreedRecommended
What happens to visits and claims in progress on the day, who is on call, and how you fall back if you must.
Insurers informedPreparation
Your main insurers know your go-live date and you have a named contact at each for the first weeks.
Start narrowPreparation
Where you can, begin with one facility or claim type and widen once volumes run cleanly.
Post-launch monitoring and maintenance
A connection that passed testing can still drift. The implementation guide is versioned, code sets are revised and insurers change their rules. Someone has to own NPHIES after the project team moves on.
Watch the queue
Unanswered, queued and failed messages, and any claim that has not moved.
Review rejections by cause
Group by error code, claim type and insurer. Fix the top cause at its source.
Reconcile and report
Billed against paid, time to payment, first-pass acceptance and rework volume.
Manage updates
Track new guide versions and code set releases, test them and schedule the change.
None of these intervals is a rule. They are a sensible starting rhythm; adjust them to your volumes. Teams with heavy claim loads often add automation here, which we cover in AI in revenue cycle management.
Common NPHIES preparation mistakes
The same handful of problems appears in most difficult go-lives. All of them are avoidable.
- Treating it as an IT project
Registration, coding and front-desk habits decide outcomes as much as the connection does. Give operations and billing real ownership.
- Leaving code mapping until testing
Mapping is the longest task for many providers. Start it at the same time as registration.
- Assuming the vendor has covered everything
An integrated system handles messages. It does not clean your data, map your codes or train your staff.
- Testing only the happy path
Deferred responses, queries, cancellations and offline insurers are part of normal operation. Test them.
- Showing staff raw error codes
If billing staff cannot tell what to fix, rejections pile up. Translate errors into actions.
- Building from an old guide or unofficial copy
Work from the current implementation guide on the NPHIES portal, and check the version before each release.
- Having no owner after go-live
Without one, rejection rates creep up unnoticed. Name the owner before cutover.
The NPHIES readiness checklist
Everything above, in one list. Tick items as you confirm them (progress is saved in this browser only), or print it for a readiness meeting.
NPHIES readiness checklist · Bonami Software · bonamisoftware.com/blog-nphies-checklist
Organization and registration
Technical integration
Eligibility and pre-authorization
Claims
Testing and go-live
After go-live
A checklist is a summary. The binding detail lives in the NPHIES implementation guide, the Academy’s registration material and CHI’s publications, all linked in the sources below.
Frequently asked questions about NPHIES
What is NPHIES?
NPHIES is the National Platform for Health and Insurance Exchange Services, Saudi Arabia’s national platform for exchanging health insurance transactions between healthcare providers and insurers. Providers use it to check eligibility, request pre-authorization, submit claims and receive payment information in a standard HL7 FHIR format. The insurance services are overseen by the Council of Health Insurance (CHI).
Is NPHIES mandatory for healthcare providers in Saudi Arabia?
For providers that bill health insurers regulated by the Council of Health Insurance, insurance transactions are exchanged through NPHIES, so in practice a working connection is a condition of being paid by those insurers. The exact obligations and dates for each provider category are set by CHI, so confirm your own position with CHI or the NPHIES onboarding team rather than relying on a third-party summary.
What do I need for NPHIES portal registration?
The NPHIES Academy lists four things for joining: the NPHIES Academy certificate, your facility’s NPHIES ID, an authorized person form stamped by the Chamber of Commerce, and a copy of the authorized person’s ID. The NPHIES ID is the 14-digit NHIC identifier obtained through the Seha platform. Requirements can change, so check the current registration guide before you submit.
Where can I find the NPHIES implementation guide and API documentation?
The implementation guide is published on the NPHIES portal at portal.nphies.sa/ig. It defines the FHIR R4 profiles, message structure, terminology, error handling and worked examples for each transaction, and it is the reference your developers or your system vendor build against. Always work from the current published version.
Which codes does NPHIES use?
Diagnoses are coded in ICD-10-AM. Services and procedures are billed using the Saudi Billing System published by CHI, and the implementation guide defines separate billing value sets for institutional, professional, pharmacy, dental and vision claims, along with code lists for medications, laboratory, imaging and medical devices. Use the versions referenced in the current implementation guide and CHI publications.
What is NPHIES integration, and can we connect through our existing HIS?
NPHIES integration means your system can build, send and receive the FHIR messages the platform expects. Providers usually connect in one of two ways: through a hospital information system or revenue cycle product whose vendor has already integrated with NPHIES, or through a direct integration built for their own system. The right route depends on your current software, transaction volumes and how much control you need.
How long does NPHIES onboarding and integration take?
There is no single published duration. It depends on how you connect, how clean your patient, coverage and coding data is, how many facilities and payers are in scope, and how many testing rounds you need. Providers using a system that is already integrated mostly work through registration, configuration and training. A direct build adds development and testing work on top of that.
Why are NPHIES claims rejected?
Common causes include patient identifiers that do not match the insurer’s record, missing or invalid required fields, codes that are not valid for the claim type, and pre-authorization references that are missing or do not match. The implementation guide separates structural errors, which stop a message being processed, from business and validation errors, which come back with rule codes. Tracking rejections by cause is the fastest way to reduce them.
Where to start this week
If you are at the beginning, three things move the rest forward: name your champion and authorized person, start the Academy course, and begin mapping your service codes. Everything technical goes faster once those are in motion.
If you are already live and rejections are the problem, start at section nine. Group a month of errors by cause, and the first fix usually becomes obvious.
Need help getting NPHIES-ready?
Bonami builds and maintains NPHIES connections alongside the HIS or billing system you already run: code mapping, eligibility, pre-authorization, claims, testing support and monitoring after go-live. Tell us where you are in the checklist and we will tell you what the next step involves.
Sources
- NPHIES: Healthcare Financial Services implementation guide, v1.0.0 (HL7 FHIR R4.0.1)
- NPHIES implementation guide: message structure and exchange
- NPHIES implementation guide: error handling
- NPHIES implementation guide: profiles and terminology
- NPHIES Academy: registration course and frequently asked questions
- Council of Health Insurance: nphies
Reviewed against the cited sources on October 12, 2026. NPHIES requirements are updated from time to time and can differ by provider type and insurer. This article is general guidance and does not replace official instructions from CHI or the NPHIES onboarding team.
