Saudi hospitals are moving onto new EHR platforms as care is reorganised around regional health clusters. The software is the visible part. The data that moves with it decides whether the new system works from day one.
Saudi Arabia is in the middle of one of the largest health system redesigns anywhere. Care delivery is being restructured around 20 regional health clusters, and with that comes a wave of EHR decisions. A 2026 market study by Black Book Research ranked Saudi Arabia first among 13 "next-wave" EHR growth markets, and described buyers moving beyond isolated hospital purchases towards platforms judged on NPHIES and health information exchange interoperability, data protection controls, cybersecurity and in-country delivery.1
Behind every one of those decisions sits a data migration. Years of patient history, held in different systems, with different codes and different ways of recording the same thing, has to arrive in the new platform intact and usable. That part rarely makes the headlines, but it decides whether clinicians trust the new system.
This article is for Saudi hospitals and health clusters planning or running an EHR change, and for the implementation, revenue cycle and data teams supporting them. It complements our guide for Dubai, Switching EMR in Dubai? 7 Things DHA Expects Before You Go Live.
Figure 1. What Saudi healthcare IT leaders prioritise when choosing a platform. Source: Black Book Research, Q2 2026. Results reflect buyer views, not certifications.
EHR projects are usually planned around configuration, integration and training. Data migration is often treated as one task near the end. In practice, cleaning, mapping and verifying years of records takes longer than installing software, and it is where most surprises appear.
When several hospitals move onto one cluster platform, the effect multiplies. Each brings its own legacy system, its own local codes and its own habits. A short data assessment at the start, covering volumes, formats, duplicates and unstructured documents, turns those surprises into a plan.
Not everything needs to migrate in full. A common approach is to bring active patients' core history across in structured form (demographics, diagnoses, medications, allergies, results and key documents) and to keep older or inactive records accessible in a read-only archive.
Whatever the approach, records that are not migrated must remain available for care, for patients and for regulators for as long as required. Retention expectations should be confirmed with the Ministry of Health, the cluster's governance and legal advisers before anything is archived or decommissioned.
Saudi Arabia has moved decisively towards national code sets. The NPHIES implementation guide expects coded data to use "internationally recognized or Saudi nationally recognized coding standards".2 For billable services in private insurance, the Saudi Billing System replaced insurers' inconsistent in-house codes with one national set of 7,947 codes.3
Legacy systems often predate these standards. Laboratory tests may sit under each hospital's local names, services under internal codes, and medicines under brand names or free text. Copying them across unchanged moves the inconsistency into the new platform, where it affects clinical decision support, reporting and every NPHIES transaction. Mapping each item to the current national standard during migration, with clinical review where meaning is uncertain, is far cheaper than fixing it afterwards.
A 2025 editorial in the Saudi Journal of Health Systems Research describes integrating EMRs across medical cities, health clusters and hospitals as an ongoing challenge, linked to incomplete records, missing medications and duplicate visits when patients move between facilities.4
Figure 2. An illustrative example. Without matching, the new platform inherits three partial patients instead of one complete one.
Experience from health information exchanges across the Gulf shows that patient matching relies on national identifiers, full names and dates of birth, and that missing or incorrect registration data breaks it.5 A migration is the best opportunity to fix this, because every record is being handled anyway. Match on the national ID or Iqama number where available, standardise names and dates, and send uncertain matches for human review rather than merging automatically.
Every hospital system accumulates documents attached to the record rather than recorded in it: reference laboratory results, outside reports, referral letters, discharge summaries and scanned paper files. Migrating them as attachments preserves them, but the results inside still cannot be trended, searched, or used in an NPHIES prior authorisation without someone opening the file.
Structuring the most valuable documents during migration, starting with laboratory results and medication histories, gives clinicians on the new platform a far more complete picture of each patient from the first day. It also gives revenue cycle teams supporting evidence they can find and send in seconds.
NPHIES carries eligibility checks, prior and advanced authorisations, claims, payment reconciliation, and information requests between providers and payers, using the FHIR R4 standard. It validates and routes these transactions, and keeps copies to support dispute resolution and regulatory processes.2
Figure 3. Planning NPHIES continuity across cutover.
These transactions do not pause for an EHR change. Before cutover, list every open prior authorisation and claim, and decide which system will complete each one. Agree a downtime process with payers for the cutover window. Afterwards, reconcile transactions between the old and new systems so nothing is lost or submitted twice. Test the new platform's NPHIES integration with realistic data before go-live, not after.
Under Saudi Arabia's Personal Data Protection Law (PDPL), fully enforceable since September 2024, health data is sensitive personal data. It may be transferred outside the Kingdom only where appropriate protection exists, with safeguards and a risk assessment for sensitive data, and accessing data remotely counts as a transfer. Breaches likely to cause harm must be reported to the regulator within 72 hours.6
Migrations often involve several outside parties: the legacy vendor, the new vendor, integration specialists and data cleaning or extraction services. Any of them may process data abroad by default or have staff accessing it from other countries. Before a migration starts, confirm for every partner where data is processed, who can access it and from where, and how long anything is kept. Please confirm your obligations with a legal adviser.
Care in Saudi Arabia is being reorganised around 20 regional health clusters, and buyers are looking for platforms that meet national interoperability, data protection, cybersecurity and in-country delivery expectations. Black Book Research ranked Saudi Arabia first among 13 next-wave EHR growth markets in 2026.
We have not found a published national guideline specific to EHR transitions. Migrations should be planned around national requirements such as NPHIES standards, national coding standards and the Personal Data Protection Law, and confirmed with the Ministry of Health and legal advisers.
Most hospitals migrate active patients' core history in structured form, including demographics, diagnoses, medications, allergies, results and key documents, and keep older records accessible in an archive. Retention expectations should be confirmed before anything is decommissioned.
Match patients on national identifiers, full names and dates of birth, standardise registration data, and send uncertain matches for human review rather than merging automatically.
Under the PDPL, health data is sensitive and may only be transferred abroad where appropriate protection exists, with safeguards and a risk assessment. Remote access from abroad counts as a transfer. Confirm your position with a legal adviser.
An EHR change is the one moment when every record is examined. Done well, it leaves a hospital with cleaner, more complete data than it started with. There are two ways we can support you.
This article is for general information and is not legal or regulatory advice.
Suhina Singh is a physician, the Founder and CEO of Jonda Health, and a health data strategist working at the intersection of artificial intelligence and clinical information systems.
