What NPHIES is
NPHIES is the national platform for health and insurance exchange services in Saudi Arabia. It was launched by the Council of Health Insurance, and healthcare providers and insurers exchange their insurance transactions through it instead of through separate bilateral connections.
Its published implementation guide for healthcare financial services is based on HL7 FHIR R4.0.1. The guide is the document your technical team builds against, and it is maintained by the platform programme, so it changes. Always work from the current version.
The six transaction groups
The implementation guide organises the exchange into six groups of transactions. Each one corresponds to a step your hospital already performs, whether by hand or in a system.
| Group | What it covers | Step in the hospital |
|---|---|---|
| Eligibility | Checking that the patient's coverage applies | Registration and the front desk |
| Authorisations | Prior authorisation and advanced authorisation requests | Clinical and insurance desk |
| Claims | Single claims and batch claims | Billing office |
| Payment | Payment notices and reconciliation | Finance |
| Communication | Sending and requesting additional information | Insurance desk and clinicians |
| Supporting | Cancellations, error notices, polling and status checks | Integration and operations |
How the messaging works
NPHIES uses FHIR messaging. The provider system, called the healthcare provider or HCP in the guide, sends a message to the NPHIES messaging endpoint, and NPHIES passes it to the insurer, called the HIC. Messages carry a MessageHeader, and the response refers back to it, so each request and response can be matched.
| Pattern | What happens |
|---|---|
| Full cycle | The provider sends a message through NPHIES to the insurer, and the response comes back through NPHIES to the provider |
| Provider to NPHIES | The provider polls for messages and notices that are waiting for it |
| Insurer to NPHIES | The insurer sends deferred responses and requests that it starts itself |
| NPHIES to insurer | NPHIES delivers error notices about earlier exchanges |
Three technical rules matter most to a hospital system. All message exchange uses mutually authenticated HTTPS with an X.509 certificate issued by NPHIES. A response is not always immediate, so the provider system must poll, and a poll returns a maximum of 100 messages. And every message must be traceable end to end by its identifiers.
What onboarding involves
NPHIES publishes its own onboarding path, and it is the operator's process that applies, not a vendor's.
- Training. The NPHIES academy runs a mandatory registration course that covers the medical, technical and business sides, including FHIR training and the HL7 artefacts.
- Portal registration. Participants register on the NPHIES unified portal to receive the documentation needed for the onboarding journey.
- Technical readiness. The readiness and activation guidance describes requirements such as a static IP address located in Saudi Arabia and a public key infrastructure certificate. Confirm the current list with the onboarding team.
- Sandbox and conformance testing. Development and testing take place in a sandbox with synthetic data, and the required profiles and transaction types are validated before activation.
- Production. Transactions in production begin after the integration requirements are completed.
Ask the NPHIES onboarding team early whether your organisation must onboard as a provider, as a technology vendor, or both. The answer decides who requests sandbox access, who holds the certificate and who signs off the tests.
What a hospital system has to support
Connecting is not the hard part. The hard part is that every step has to work inside the hospital before it can work through a platform.
- Coverage held per patient with the identifiers the platform expects, and an eligibility check that stores its answer.
- Prior authorisation requested from the clinical workflow, with the approval, its validity and any amount limit recorded.
- Claims built from the same charges the patient was billed, with the service, diagnosis and medicine coding the guide requires.
- Responses handled in both modes: immediate and polled later.
- Rejections worked by a named team, with resubmission tracked.
- Payment notices matched to claims, so finance can reconcile.
- Certificate renewal, IP allow-listing and sandbox versus production separation owned by IT.
Design points that prevent the common failures
- Idempotency. A retry must not create a second claim. Keep the identifier of every request and check it before resending.
- Correlation. Store the message identifiers you send and the ones you receive, and keep the link between them.
- Asynchronous responses. Treat "no answer yet" as a state, not as an error, and poll on a schedule you can monitor.
- Coding maps. Service, medicine and diagnosis mappings need owners and review, because a wrong code is a rejected claim.
- Monitoring. Alert a named person when messages queue, fail or stop arriving, and keep a downtime procedure for each step.
How Ventrecs approaches NPHIES
The Ventrecs insurance module already holds the parts of the workflow that a platform exchange depends on: payers, plans and benefit rules, patient coverages with a priority, eligibility checks, pre-authorisation with an approval number and validity, claims with a defined lifecycle, and the response from the payer applied to each line. Eligibility can use a generic REST connector or a FHIR R4 CoverageEligibilityRequest connector, and claims can be exported as a FHIR R4 Claim.
National claim and exchange schemes have their own specifications, credentials and onboarding, so Ventrecs delivers them as interface adapters scoped per project, through a durable outbox with retry and a transaction log. We do not claim that Ventrecs is certified or approved by NPHIES. Status is agreed with you, and tested against the operator's sandbox, before go-live.
Sources
- NPHIES Healthcare Financial Services implementation guide
- NPHIES implementation guide: message exchange
- NPHIES academy: registering in the platform
Frequently asked questions
What FHIR version does NPHIES use?
The published implementation guide for healthcare financial services is based on FHIR R4.0.1.
Does a hospital connect directly to insurers?
No. Providers and insurers exchange messages through NPHIES, which validates and routes them. Insurers expose their own endpoint to NPHIES.
How are responses delivered?
Some come back immediately. Others are deferred, so the provider system polls NPHIES, and a poll returns a maximum of 100 messages.
Is Ventrecs certified by NPHIES?
No claim is made. An NPHIES adapter is scoped per project and tested against the operator's sandbox, and the status is agreed with the customer.
Related Ventrecs pages
- Insurance and claims Payers, plans, pre-authorisation, eligibility checks and claims.
- Integrations How Ventrecs scopes, tests and supports each connection.
- Ventrecs Connect The governed integration hub: monitoring, retries and reconciliation.
- Solutions by provider type Medical centres, laboratories, imaging centres, pharmacy groups and hospital networks.
Planning a deployment?
Tell us about your facility and your insurance workflows. We can map the questions to answer before any connection to NPHIES is scoped.
More insights
- HL7 v2 or FHIR R4? How to choose for a hospital integration Most hospitals will use both. The useful question is which standard each partner publishes, and where to translate between them.
- Healthcare integration readiness: scope every interface before go-live Most delays in a healthcare deployment come from interfaces nobody scoped. Use this guide to agree each connection, its owner and how it is tested before go-live.
- Hospital information system RFP checklist: how to evaluate HIS, EMR, LIS, RIS and pharmacy requirements A good RFP asks for evidence, not features. Use this checklist to define scope, requirements, demonstrations and scoring before you issue it.