Interoperability is the least glamorous word in healthtech and the most decisive one. A scheduling app, a lab system, and a national insurance platform are only as useful as their ability to exchange a patient record without a human re-typing it. Across MENA, the gap between a FHIR tutorial and a working deployment in a Tunis polyclinic or a Gulf hospital group is exactly where projects live or die.
The standards question is largely settled: HL7 FHIR won. The regional questions — patient identity across two scripts, clinics with intermittent connectivity, data residency rules that differ by country — are where the real engineering happens. This post covers both layers.
FHIR is the default, so profile it properly
FHIR R4 is the pragmatic baseline: it is what vendors ship, what national programs mandate, and what integration engines understand. R5 exists, but choosing it today means swimming against the tooling. The model is REST plus JSON resources — Patient, Encounter, Observation, MedicationRequest, DiagnosticReport — with OAuth 2.0 and SMART on FHIR handling application authorization.
The region gives FHIR real anchors. Saudi Arabia's nphies platform standardized health insurance exchange on FHIR-based messages, forcing an entire market of payers and providers through conformance testing. The UAE runs health information exchanges in Abu Dhabi and Dubai that give integration work concrete targets. In the Maghreb, national programs are earlier-stage, which cuts both ways: less mandated structure, more freedom to build on clean R4 profiles from the start.
The discipline that matters is profiling. Base FHIR is deliberately loose — almost everything is optional. A deployment needs published profiles stating which fields are required, which terminologies bind where, and which extensions exist. Write them down in an implementation guide, even a short one; undocumented deviations are the interoperability debt that compounds fastest.
Patient identity is the hardest regional problem
Patient matching is difficult everywhere; MENA adds specific twists.
- ▸Two scripts, many transliterations: the same patient may be registered in Arabic script at one facility and in Latin transliteration at another, and transliteration is not deterministic — one Arabic name yields several plausible Latin spellings. Deterministic matching on names alone will silently fragment records.
- ▸Inconsistent identifier capture: national ID coverage is good on paper, but front-desk reality includes missing cards, guardians registering children, and legacy systems that never stored the number. Treat national IDs as a strong signal, not a guaranteed key.
- ▸The fix is a matching service: a dedicated component combining deterministic rules on identifiers with probabilistic scoring on normalized names, birth dates, and phone numbers — with a human review queue for the ambiguous middle. Build it early; retrofitting identity resolution across a year of fragmented records is miserable, expensive work.
Terminology needs the same realism. ICD-10 is ubiquitous for diagnoses and LOINC is the sane choice for labs, but SNOMED CT licensing depends on national membership, which varies across the region — verify the licensing position for each deployment country before you depend on it.
Design for the connection you actually have
Urban hospitals in the Gulf have excellent connectivity. A rural clinic in the interior of Tunisia or Egypt may not, and a system that assumes an always-on link will be abandoned by week two.
Offline-first is an architecture, not a feature flag: local storage at the facility, a durable outbound queue, store-and-forward synchronization, and idempotent upserts on the receiving side so replayed messages cannot double-create records. Conflict resolution rules must be explicit — clinical safety usually argues for preserving both versions and surfacing the conflict rather than silently merging. Imaging deserves separate treatment: DICOM studies are orders of magnitude larger than FHIR payloads, so plan local caching and deferred upload rather than pushing everything through the same pipe.
Residency and consent are per-country facts
Health data is the most regulated data class in every MENA jurisdiction, and the rules do not harmonize. The UAE requires health data to remain in-country absent specific exemptions. Saudi Arabia's PDPL adds general personal-data obligations on top of health-sector rules. Tunisia's data protection law predates GDPR and comes with an authority, the INPDP, whose authorization matters for health data processing. The architectural consequence: region-pinned storage per deployment, encryption at rest and in transit as table stakes, and consent modeled explicitly — FHIR's Consent resource exists precisely so that consent travels with the data instead of living in a filing cabinet.
A deployment sequence that survives contact with clinics
1. Map the paper and legacy flows first; the fax machine and the Excel export are requirements, not embarrassments. 2. Stand up an integration engine — Mirth Connect or OpenHIM — instead of point-to-point interfaces you will maintain forever. 3. Publish FHIR R4 profiles and an implementation guide before the first integration, not after the third. 4. Build the patient-matching service early, with a review queue staffed from day one. 5. Pin storage per jurisdiction and document the residency position for each country in writing. 6. Pilot with clinicians on real workflows; demo data hides every problem that matters.
The payoff for getting this right is not abstract. Interoperable records cut duplicate tests, make referrals traceable, and turn insurance claims from paperwork into pipelines. For healthtech builders, MENA's fragmentation is the opportunity: the systems being built now will define the region's health data infrastructure for a decade, and the teams that respect both the standards and the local constraints will be the ones still deployed when that decade ends.