HL7 & FHIR Integration in Saudi Arabia

A Saudi hospital runs on conversations between systems. The HIS registers the patient, the LIS receives the order and returns the result, the RIS schedules the scan while PACS stores the images, and the revenue cycle sends the claim to NPHIES. When any of these conversations breaks, staff re-key data, results go missing and claims are rejected. HL7 and FHIR integration is the engineering that keeps them reliable: HL7 v2 messaging inside the facility, HL7 FHIR R4 for national platforms such as NPHIES, and DICOM for imaging. Superior Business Solutions (SBS) designs, builds and supports these interfaces for hospitals, polyclinics, laboratories, imaging centres and pharmacies across Saudi Arabia, drawing on more than 14 years of healthcare-IT and ERP delivery.

What SBS delivers

• Interface catalogue and design: every system, message, trigger and owner documented, with field-level specifications agreed with each vendor.
• Integration engine: a central hub that validates, transforms, logs and replays messages instead of fragile point-to-point links.
• NPHIES connectivity: eligibility, pre-authorisation, claims and payment reconciliation from your HIS or RCM system.
• Terminology mapping: service masters mapped to the code sets Saudi payers and platforms expect.
• Testing, monitoring and support: vendor coordination, platform test preparation and monitored support after go-live.

Integration patterns: HL7 v2, FHIR, DICOM and IHE

HL7 v2 inside the hospital

Most HIS, LIS and RIS products in the Kingdom still exchange data as HL7 v2 messages over MLLP, and a handful of message types runs a whole hospital. ADT events (A01 admit, A04 register, A08 update, A40 merge) keep every system's patient list in step; ORM/OML carry lab and radiology orders; ORU returns results; SIU shares appointments; MDM moves documents such as discharge summaries; and DFT posts charges to billing. The hard part is rarely syntax; it is agreeing Z-segments, identifiers, code tables and acknowledgement rules with each vendor, then enforcing them.

FHIR R4 for national platforms and apps

NPHIES is built on HL7 FHIR R4. Transactions travel as FHIR message bundles built from resources such as CoverageEligibilityRequest, Claim (used for both pre-authorisation and claims), ClaimResponse, Communication and PaymentReconciliation, and are validated against the platform's implementation guide. Some responses arrive asynchronously, so your system must retrieve and match them later rather than wait. FHIR also suits patient apps, portals and analytics, over REST APIs secured with OAuth 2.0 and SMART on FHIR.

DICOM and IHE profiles

Imaging depends on DICOM: the modality pulls its schedule from a modality worklist fed by RIS orders, reports progress through MPPS and sends the study to PACS. IHE profiles give these flows a tested shape: Scheduled Workflow for radiology, PIX/PDQ for patient identity across systems, XDS and XDS-I for sharing documents and images, and ATNA for audit trails and authenticated connections.

One engine, not point-to-point links

A hub-and-spoke engine replaces fragile point-to-point links and gives one place to monitor and replay traffic. Engines common in the region include Mirth Connect (NextGen Connect), Rhapsody and InterSystems IRIS for Health. Their licensing models differ, and some have changed recently, so engine choice belongs in the first cost conversation. If you already own an engine, we build on it.

Terminology mapping to Saudi code sets

A well-formed message still fails if its codes are wrong. NPHIES expects ICD-10-AM diagnoses, procedure and service codes from CHI's Saudi Billing System (derived from the Australian ACHI classification) and SFDA identifiers for medications. Internally, laboratory tests are ideally mapped to LOINC and clinical findings to SNOMED CT where the receiving system supports them. We build and maintain the mapping from each service master to the standard code sets, because many claim rejections start there.

Saudi platforms and rules that shape interface design

NPHIES and the Council of Health Insurance

NPHIES is the national platform through which providers and insurers exchange eligibility, pre-authorisation, claims and payment information, operating under the Council of Health Insurance (CHI, formerly CCHI). Providers and their system vendors complete the platform's onboarding and testing before live submission, and the implementation guide evolves, so interfaces should be versioned, configuration-driven and regression-tested with each release. Eligibility depends on the national ID, Iqama or other official identifier being captured correctly at registration.

The national health information exchange

Beyond insurance, the Kingdom is building shared clinical records. The National Health Information Center (NHIC) publishes the policies and interoperability standards for the Saudi Health Information Exchange, covering patient identity, consent, privacy and clinical documents. Which facilities connect, and through which profiles, depends on the programme's current phase and your sector, so every HIE engagement starts from the latest published specification.

CBAHI, NCA ECC and PDPL

CBAHI accreditation expects records that are complete, timely, secure and traceable; an interface that silently drops a critical result or duplicates a patient becomes an accreditation finding, not just an IT ticket. The National Cybersecurity Authority's Essential Cybersecurity Controls bind government entities, their companies and organisations that own, operate or host critical national infrastructure, integration servers included; for everyone else they are sound practice. The Personal Data Protection Law, supervised by SDAIA, treats health data as sensitive and restricts transfers outside the Kingdom, which decides where the engine, its logs and its message archive can be hosted.

Interfaces SBS typically builds

Testing, go-live and monitoring

1. Discovery: interface catalogue, volumes and a gap list against NPHIES and departmental requirements.
2. Specification: message profiles, field mappings, code tables and error handling signed off by each vendor.
3. Build and unit test: channels on the engine, tested with synthetic and anonymised messages.
4. Integrated and platform testing: end-to-end scenarios with every vendor, then the NPHIES test environment and onboarding steps.
5. Cutover: controlled go-live with parallel checks on results and claims, and a rollback plan.
6. Run: alerts on queue build-up, NACKs, latency and rejected claims, with message replay and a dedicated support team.

What drives the cost

• The number of systems and interfaces, and the message types each carries.
• Vendor interface fees: many HIS, LIS and PACS vendors charge to enable or change an interface.
• Engine licensing and hosting, on premises or in a Saudi-hosted cloud.
• Terminology work: the size and quality of your service master.
• NPHIES scope: eligibility only, or the full cycle including communications and reconciliation.
• Security controls required by NCA ECC, PDPL and internal policy, and the support hours you need.

SBS quotes after a short discovery against a fixed interface catalogue, so you know exactly what is in scope.

How to choose an integration partner in Saudi Arabia

• Do they work from the current NPHIES implementation guide and know the onboarding steps?
• Do they map terminology to Saudi code sets, or only move messages?
• Will interfaces run on an engine with monitoring, replay and audit logs you can inspect?
• Do they handle Arabic properly: UTF-8 end to end, Arabic and English names, Hijri-to-Gregorian dates?
• Can they host and operate interfaces in line with NCA ECC and PDPL?
• Do they understand the clinical and financial processes behind each message, including insurance and TPA management?

Frequently asked questions

How much does HL7 or FHIR integration cost in Saudi Arabia?

Cost depends on the number of interfaces, vendor interface fees, integration-engine licensing, hosting and the scope of NPHIES transactions. SBS prices against a fixed interface catalogue after a short discovery, so there are no open-ended estimates.

How long does NPHIES integration take?

It depends on whether your HIS already supports the current NPHIES implementation guide, how clean your service-code mapping is and when onboarding tests are scheduled. A single well-specified interface typically takes weeks, while a multi-system programme covering NPHIES, LIS, PACS and ERP runs over several months.

Does NPHIES use HL7 v2 or FHIR?

NPHIES is built on HL7 FHIR R4 and exchanges message bundles for eligibility, pre-authorisation, claims and payment reconciliation. Most internal hospital interfaces still use HL7 v2, so an integration engine usually bridges the two.

Do we have to go through NPHIES onboarding and testing?

Yes. Providers and the systems they use complete the platform's onboarding and testing steps under the Council of Health Insurance before live submission. SBS prepares your interfaces and test cases and supports you through the process; approval comes from the platform, not from SBS.

Can the interfaces handle Arabic patient data?

Yes. SBS configures UTF-8 encoding end to end, carries Arabic and English names in the right fields and converts Hijri dates to the Gregorian formats HL7 and FHIR expect, so data stays readable in every connected system.

How are integrations secured under NCA ECC and PDPL?

Connections use encrypted transport (TLS, VPN or mutually authenticated APIs), least-privilege accounts and full audit logging, with engines and message archives hosted in the Kingdom where PDPL requires it. Where NCA ECC applies to your organisation, the integration layer is designed and documented against those controls.