With more than 24 million registered users covering roughly 68.5% of Saudi Arabia's population, Sehhaty is no longer just a government health app. It is the national digital health infrastructure layer. Saudi citizens and residents use it to access vaccination records, book appointments, retrieve lab results, receive e-prescriptions, issue sick leave certificates, and manage their medical history through a unified Health Wallet.

Any private healthcare application that operates beside Sehhaty instead of connecting to it creates fragmented patient records and broken continuity of care. Saudi users will not maintain two separate health ecosystems.

This guide from LogioLegion explains how Sehhaty integration actually works — the Saudi health platforms involved, the FHIR standards required, the authentication and consent flow, and what integration means for different categories of healthcare apps.

What Sehhaty actually is — and why it matters for private app developers

Sehhaty began as a consolidation project.

Saudi Arabia merged multiple standalone government health platforms — including Mawid, Seha, Tetamman, and RSD-related services — into a single national health super-app operated by the Ministry of Health.

Today, Sehhaty functions as the primary digital health layer for the Kingdom.

The platform handles:

• Appointment booking
• Teleconsultation
• Vaccination tracking
• Health Wallet records
• E-prescriptions
• Medication reminders
• Sick leave issuance
• Chronic disease management
• Wearable integrations
• Children's vaccination schedules
• AI-powered health interactions

For private developers, the critical point is simple: Sehhaty is now the authoritative source of patient health data in Saudi Arabia.

A wellness app that ignores Sehhaty cannot access verified vaccination records. A telemedicine app without Sehhaty integration cannot issue officially recognised sick leave certificates. A chronic disease management platform without Sehhaty connectivity forces patients to re-enter medical history manually.

Saudi users increasingly expect healthcare continuity across providers.

That expectation only works when private platforms connect to the national health ecosystem instead of operating independently.

The sick leave use case matters especially for telemedicine founders. Only Sehhaty-connected sick leave certificates receive universal recognition from Saudi employers and government entities. A telemedicine platform without official MOH-connected sick leave workflows immediately loses trust and retention.

The Saudi digital health ecosystem — the five platforms your app must know

1. Sehhaty (MOH consumer platform)

Sehhaty is the citizen-facing national health platform operated by the Saudi Ministry of Health.

Private healthcare applications interact with Sehhaty through MOH-authorised APIs tied to patient consent workflows. Access is permissioned and controlled through Nafath authentication.

Consumer-facing applications usually receive read access to:

• Vaccination history
• Prescription records
• Lab results
• Medical summaries
• Appointment history

Clinical systems such as hospitals, telemedicine platforms, and healthcare providers may receive broader read/write permissions for continuity-of-care workflows.

Consent remains granular.

Patients separately authorise:

• Medical records access
• Prescription access
• Vaccination history
• Lab result visibility

This matters architecturally because applications must handle consent scopes individually rather than assuming blanket access to patient data.

2. NPHIES (National Platform for Health Information Exchange)

NPHIES is the backend clinical and financial exchange infrastructure for Saudi healthcare.

Operated jointly by the Council of Cooperative Health Insurance (CCHI) and the National Health Information Centre (NHIC), NPHIES handles:

• Insurance eligibility checks
• Prior authorisations
• Clinical data exchange
• Claims processing
• Prescription workflows

Any healthcare provider accepting insured patients must connect to NPHIES. Hospitals and clinics that cannot submit claims through NPHIES cannot receive reimbursement from insurers.

Technically, NPHIES standardises Saudi healthcare interoperability around HL7 FHIR R4.

Clinical records move through the system as structured FHIR message bundles exchanged through the central $process-message gateway endpoint.

Examples include:

• FHIR Patient resources
• FHIR Appointment resources
• FHIR Claim resources
• FHIR MedicationRequest resources
• FHIR Encounter resources

Every organisation connecting to NPHIES receives PKI-based authentication credentials for secure message signing and validation.

This is not optional infrastructure. It is mandatory national healthcare plumbing.

3. Nafath (national digital identity — the authentication gateway)

Nafath handles patient authentication and consent.

Every Saudi healthcare application accessing patient data must implement Nafath OAuth flows. Patients authenticate using National ID or Iqama credentials through the Nafath mobile ecosystem.

The flow works like this:

1. Patient taps "Connect Health Records"
2. App redirects to Nafath authentication
3. Patient authenticates biometrically
4. Patient grants consent for specific data categories
5. Application receives scoped OAuth access tokens
6. FHIR API requests use these tokens to access approved data

No application can legally or technically bypass Nafath consent enforcement.

The access controls exist directly at the API layer, not merely inside policy documentation.

4. RSD (Rational Use of Medications — SFDA medication database)

RSD functions as Saudi Arabia's national medication reference database managed by the Saudi Food and Drug Authority.

Any application involving:

• Medication management
• E-prescriptions
• Drug interaction checks
• Pharmacy workflows
• Prescription tracking

must reference Saudi-approved RSD medication codes.

Developers frequently underestimate this requirement.

Using generic international medication coding systems without Saudi RSD mapping creates prescription mismatches and insurance claim rejection issues inside NPHIES workflows.

All medication-based FHIR requests submitted through NPHIES must align with RSD-approved coding structures.

5. Mawid (government appointment layer — within Sehhaty)

Mawid originally operated as a standalone government appointment system for MOH primary healthcare centres.

Today, Mawid functionality lives inside Sehhaty.

Applications that want to let users:

• Book MOH clinic appointments
• Reschedule government appointments
• Sync appointment availability
• Display referral pathways

must connect to the Mawid appointment layer integrated into the broader Sehhaty ecosystem.

This becomes especially important for:

• Telemedicine platforms
• Referral systems
• Chronic disease management apps
• Hospital networks coordinating with public healthcare infrastructure

Without Mawid integration, private healthcare applications cannot participate in government appointment continuity.

How Sehhaty integration actually works technically

HL7 FHIR R4 — the mandatory Saudi health data standard

Saudi healthcare interoperability runs on HL7 FHIR R4.

All clinical information exchanged through NPHIES and connected MOH systems uses structured FHIR resources.

Examples include:

• Patient demographics → FHIR Patient
• Appointments → FHIR Appointment
• Clinical encounters → FHIR Encounter
• Lab results → FHIR Observation
• Diagnoses → FHIR Condition
• Prescriptions → FHIR MedicationRequest
• Insurance claims → FHIR Claim

Most private clinics and hospitals still operate legacy systems built around HL7 v2 or proprietary database structures.

This creates the core integration challenge.

Healthcare apps usually need middleware that transforms legacy clinical data into FHIR R4 resources before transmitting information through NPHIES or MOH-connected APIs.

Without this translation layer, interoperability breaks immediately.

The authentication and consent architecture

Saudi health integrations operate around patient-controlled consent.

The standard flow looks like this:

1. User opens the healthcare app
2. App initiates Nafath OAuth
3. User authenticates via National ID or Iqama
4. User approves specific health data scopes
5. OAuth access token gets issued
6. Application calls MOH/NPHIES APIs
7. Token refresh and expiry handling continues in the background

Tokens remain scoped to approved data categories.

For example:

• Vaccination access does not automatically grant prescription access
• Lab result access does not imply medical history access

Applications must architect consent management carefully.

Data residency and hosting requirements

Saudi health data cannot freely move across jurisdictions.

Applications integrating with Sehhaty or NPHIES must store patient health data within approved Saudi-compatible infrastructure environments.

Most Saudi healthcare projects deploy on:

• AWS Middle East (Bahrain)
• Saudi government-approved cloud environments

Processing patient health records outside the Kingdom requires explicit regulatory approval.

This affects:

• Infrastructure design
• Disaster recovery planning
• Analytics architecture
• AI model deployment
• Backup storage strategy

Security requirements for production approval

Saudi healthcare systems operate under strict security expectations.

Production-grade health applications typically require:

• TLS 1.3 encryption in transit
• AES-256 encryption at rest
• Role-based access control (RBAC)
• Full audit logging
• PKI certificates for authenticated transactions

Audit logs must track:

• Data access events
• Record modifications
• User identity
• Timestamps
• Access categories

Healthcare organisations also restrict practitioner visibility to patients under active care relationships.

Integration use cases by healthcare app category

Consumer wellness and chronic disease apps

Patient-facing wellness apps usually receive read-focused integrations.

Typical use cases include:

• Pulling vaccination history from Sehhaty
• Displaying medication records
• Showing lab results
• Reading wearable health data
• Syncing activity metrics

Most consumer wellness applications do not receive permission to write directly into clinical health records.

Their role typically centres around engagement, tracking, and patient visibility.

Clinic and hospital systems (HIS/EHR)

Hospitals and clinics require full NPHIES integration.

Core workflows include:

• Insurance eligibility verification
• Prior authorisation requests
• Claims submission
• Clinical data exchange
• Prescription management
• Continuity-of-care updates

Insurance claims flow through structured FHIR Claim resources routed through the NPHIES gateway.

Medication prescribing also requires RSD-compliant medication coding.

Without NPHIES connectivity, reimbursement operations stop functioning.

Telemedicine platforms

Telemedicine integrations become more complex because they combine clinical workflows with patient-facing UX.

Typical architecture includes:

• Nafath patient authentication
• Medical history retrieval before consultation
• Encounter record creation post-consultation
• E-prescription issuance
• Sick leave certificate generation
• Insurance claim submission

Encounter summaries usually write back into the patient's longitudinal health record through FHIR Encounter resources.

E-prescriptions route through FHIR MedicationRequest structures using RSD-approved medication codes.

Most importantly, official sick leave issuance must happen through MOH-connected APIs. Without this integration, telemedicine products lose one of the most commercially important workflows in Saudi digital health.

Pharmacy applications

Pharmacy systems interact heavily with prescription verification workflows.

Core integrations include:

• Sehhaty prescription verification
• Medication dispense confirmation
• Drug interaction checking
• RSD code validation

Once medication gets dispensed, the pharmacy application usually pushes dispense confirmation back into the national health record ecosystem.

This closes the prescription lifecycle and improves continuity of care across providers.

What happens if you don't integrate with Sehhaty and NPHIES

Saudi healthcare apps that ignore national integrations create fragmented experiences immediately.

Patients cannot access verified health records inside the application. Instead, they manually enter medical history repeatedly.

Telemedicine platforms cannot issue officially recognised sick leave certificates.

Hospitals and clinics cannot process insurance claims through NPHIES.

Pharmacy applications cannot verify external e-prescriptions.

Applications also lose eligibility for broader MOH ecosystem participation and future interoperability initiatives.

The longer founders delay integration planning, the more expensive retrofitting becomes later.

Saudi healthcare policy increasingly moves toward deeper ecosystem interoperability, not less.

AI features emerging inside Saudi healthcare apps

Saudi digital health infrastructure increasingly supports AI-powered care experiences.

Healthcare startups now build:

• AI symptom triage
• Predictive health analytics
• Medication adherence coaching
• Chronic disease monitoring
• Personalised preventive health recommendations

Sehhaty itself already supports large-scale AI interaction workflows across chatbot and patient engagement systems.

AI layers work best when combined with verified national health data.

A diabetes management application connected to Sehhaty can personalise recommendations using real medication history, lab results, and consultation patterns instead of relying entirely on patient self-reporting.

Predictive healthcare systems also improve significantly when built on longitudinal patient records rather than fragmented application-specific data.

For the AI infrastructure powering Arabic healthcare assistants, predictive analytics, and multilingual health coaching systems, see our guide to the best agentic AI models in 2026.

The broader Saudi healthcare compliance landscape

Sehhaty integration represents one part of Saudi healthcare compliance.

Healthcare applications must also evaluate:

• CBAHI operational requirements
• SFDA medical software rules
• PHIE interoperability obligations
• Saudi health data privacy frameworks
• Clinical audit requirements

This becomes especially important for:

• Telemedicine platforms
• AI-powered diagnostic tools
• Remote monitoring systems
• Clinical workflow software
• Connected medical devices

For a deeper breakdown of Saudi healthcare compliance architecture beyond Sehhaty connectivity, read building a Saudi healthcare app: CBAHI, PHIE, SFDA compliance.

How long does Sehhaty and NPHIES integration take — and what does it cost?

The timeline depends heavily on the complexity of your healthcare workflows and whether you are integrating as a consumer application or a clinical provider system.

Consumer health app integration

Includes:

• Nafath authentication
• Sehhaty read access
• Vaccination and prescription retrieval
• Health Wallet visibility
• Arabic RTL mobile application
• Basic audit logging

Timeline: 10–16 weeks

Cost: SAR 80,000 – SAR 180,000

Telemedicine or clinic platform integration

Includes:

• Full FHIR middleware
• Sehhaty read/write integration
• NPHIES claims workflows
• E-prescription issuance
• Sick leave API integration
• RSD medication coding
• Insurance eligibility verification

Timeline: 20–36 weeks

Cost: SAR 220,000 – SAR 650,000

Enterprise hospital or multi-provider integration

Includes:

• Full HIS/EHR integration
• Multi-facility NPHIES orchestration
• Real-time FHIR transformation engine
• Advanced RBAC
• Data warehouse architecture
• AI analytics integrations
• Enterprise audit systems

Timeline: 40–72 weeks

Cost: SAR 750,000 – SAR 2,500,000+

Infrastructure, compliance audits, PKI certification, and regulatory consulting remain separate from core software development budgets.

Book a free discovery call to scope your healthcare platform architecture, integration complexity, and regulatory path.

5 mistakes Saudi healthcare founders make when building connected health apps

Treating Sehhaty like a simple third-party API
Sehhaty integration affects authentication, data architecture, compliance, consent flows, and hosting decisions. It changes the entire application design.

Ignoring FHIR until late in development
FHIR is not a reporting export format added later. Saudi healthcare interoperability depends on FHIR-native architecture from the start.

Building without Nafath consent workflows
No healthcare application can legally access patient records without authenticated consent. Consent architecture belongs inside onboarding from day one.

Hosting health data outside Saudi-approved infrastructure
Healthcare data residency rules are strict. Fixing non-compliant infrastructure later creates major migration risk and regulatory exposure.

Assuming telemedicine works without official sick leave integration
Saudi patients expect officially recognised documentation. A telemedicine platform without MOH-connected sick leave workflows loses trust quickly.

Why LogioLegion for Saudi healthcare app development

LogioLegion builds healthcare platforms around Saudi interoperability and compliance realities from the beginning. Our team develops FHIR integration middleware in Node.js, clinical workflow systems in Laravel, patient-facing mobile apps in React Native, and operational dashboards in Next.js.

We architect Saudi healthcare systems with Nafath authentication, NPHIES message handling, Arabic RTL support, and AWS Bahrain data residency as standard requirements — not optional upgrades later.

Our Dubai and India presence gives healthcare founders access to GCC-aware engineering execution with deep understanding of Saudi government platform integrations, healthcare compliance workflows, and bilingual patient experience design.

Conclusion

Saudi Arabia's healthcare market increasingly operates as one connected digital ecosystem built around Sehhaty, NPHIES, Nafath, and MOH interoperability standards.

Healthcare applications that integrate properly gain access to verified patient records, insurance workflows, official documentation systems, and continuity-of-care infrastructure that standalone apps simply cannot provide.

The technical complexity is real. FHIR transformation, consent architecture, PKI authentication, data residency, and healthcare compliance all need careful planning from the beginning.

The founders and healthcare providers who build integration-first products will define the next generation of Saudi digital health.

Ready to integrate your healthcare platform with Saudi Arabia's national health infrastructure? Book a free discovery call with LogioLegion — we'll map your integration architecture, compliance requirements, and development roadmap.

---