Clinical Documentation AI in Arabic Healthcare: A GCC-Contextual Framework

1. Introduction

Documentation burden is now one of the most-cited contributors to physician burnout globally, and in GCC hospitals the burden is amplified by a specific linguistic and regulatory context that off-the-shelf clinical AI has not been designed for. The overwhelming majority of publicly available medical language models are trained on English corpora and evaluated against English benchmarks. When deployed in a hospital where physicians and patients transact in a mixture of Modern Standard Arabic (MSA), Gulf dialects, and English medical terminology, these systems produce documentation that is either linguistically thin, factually unstable, or both.

This paper reports observations from ongoing production and pre-production deployments of a clinical documentation AI system, Historian, developed by INFINITEWARE and deployed in GCC healthcare settings. Our purpose is not to argue that AI-assisted documentation is inevitable, but to specify what such a system must do to be safe and useful in this context, and where the current generation of general-purpose systems falls short.

2. The clinical documentation problem in GCC hospitals

Studies of physician time-on-task in high-income health systems consistently report between one and two hours of documentation for every hour of direct patient care. We do not have equivalent published measurements for GCC systems, but interviews and shadowing sessions with physicians in Bahraini and other Gulf hospitals suggest that the ratio is broadly similar, with two additional pressures. First, patient encounters are almost never conducted in a single language: a consultation may open in Gulf-dialect Arabic, transition to MSA when the physician summarises findings for the record, and switch to English when medical terminology is required. Second, the electronic medical record itself is typically English-language, meaning that a natively bilingual encounter is being compressed into a monolingual write-up in real time by the physician.

The consequence, well-documented outside the Gulf and consistent with what we have observed, is that a substantial fraction of clinical detail is lost between the consultation and the record. The lost detail is disproportionately the qualitative context that patients express in their first language, and disproportionately the physician's reasoning trail. Both are exactly the material that a good clinical documentation system would preserve.

3. Why global LLMs underperform on clinical Arabic

The performance of general-purpose large language models on Arabic clinical text is not a single problem but three overlapping ones.

First, training corpus composition. Publicly reported training mixes for the frontier models include Arabic at single-digit percentages of the total corpus. Within that Arabic subset, medical content is a small fraction, and Gulf-dialect content smaller still. This produces systems that can generate fluent MSA on general topics but exhibit noticeable degradation on medical Arabic, and near-total failure on the code-switched clinical Arabic encountered in Gulf hospitals.

Second, terminology handling. Medical Arabic in the Gulf routinely mixes transliterated English terms (MRI, CBC, stat) with Arabic clinical vocabulary, sometimes in the same sentence. General-purpose Arabic language models are not calibrated for this and either over-translate, producing awkward pure-Arabic renderings that no physician would use, or under-translate, dropping the Arabic context entirely.

Third, dialect coverage. Written medical documentation in the Gulf is conducted in MSA or English, but the source material, the patient's speech, is in dialect. A system that only handles MSA will silently discard the dialect layer during transcription or summarisation. The lost information is systematically the material that carries symptoms, history, and social context.

4. Framework: Four requirements

From the observed failure modes, we propose four requirements that any clinical documentation AI intended for GCC deployment must satisfy. We treat these as jointly necessary rather than as a scoring rubric. A system that satisfies three of the four does not partially work. It fails in production at the missing requirement.

• Arabic medical corpus with dialect coverage. The language model must be trained or fine-tuned on a corpus that includes medical Arabic and Gulf dialect coverage. General-purpose Arabic fine-tunes are insufficient. In practice this means either building a dialect-inclusive medical corpus in-region, or fine-tuning against physician-labelled data drawn from the deployment context.
• Sovereign or on-premise hosting. Patient-identifying data must not leave the hospital, both for regulatory reasons that vary by GCC state, and for the practical reason that trust is a prerequisite for physician adoption. Cloud-hosted models with API-based access to identifiable clinical data have been rejected in every deployment context we have observed. Systems must be capable of running fully within the hospital's network boundary.
• Standards-compliant EMR integration. Documentation that lives outside the EMR is documentation that is not used. Systems must integrate at the record level through HL7 FHIR profiles or equivalent, and must round-trip changes back into the record without physician re-entry. In practice this is where the majority of deployment work is spent.
• Workflow-native capture. The AI capture path must fit into the existing physician workflow, whether that is ambient scribing during the consultation, structured post-encounter dictation, or template-based note completion. Systems that require the physician to change how they conduct the encounter fail regardless of model quality.

5. Field observations

The remainder of this paper reports observations from production and pre-production deployments of Historian in GCC hospitals. We report qualitative patterns rather than aggregate metrics, because sample sizes remain small and the deployment sites vary in size, specialty mix, and integration depth.

Time savings are real but not uniform.

Across observed deployments, physicians report meaningful reductions in per-encounter documentation time. The magnitude varies substantially by specialty and by physician. High-throughput outpatient contexts see the largest benefits. Specialties with heavily-structured note formats (radiology, pathology) see smaller marginal benefits, because the template already carries most of the structure the AI would otherwise infer.

Acceptance follows verification.

Physician trust in AI-generated documentation is not established by system-level accuracy claims. It is established by the physician being able to inspect and edit the generated note in the same interface used for manual documentation. Systems that present the AI output as a black-box approve-or-reject gate are rejected. Systems that expose the AI output as an editable draft in the physician's existing note field are accepted. The interface pattern matters at least as much as the model quality.

Failure modes are visible, not silent.

The failure modes we have observed cluster into three categories: dialect miscomprehension, where the model produces MSA where the patient's expression carried clinical detail that MSA does not preserve; terminology drift, where transliterated terms are inconsistent across notes; and structural omission, where the AI produces a well-formed note that omits a section the physician expected. In each case the physician catches the failure during review. This is desired behaviour and should not be mistaken for a shortcoming of the AI: the whole design intent is that the physician remains the responsible clinician.

A clinical documentation AI does not become safe by being right most of the time. It becomes safe by being wrong in ways that a physician can see and correct in the same workflow they already use.

6. Limitations and open questions

Several limitations of this framework and of the observations reported here should be stated.

The observations are drawn from a limited number of sites and cannot be generalised to GCC healthcare as a whole. The dialect coverage requirement is stated as necessary but the paper does not resolve the question of how much dialect coverage is sufficient, and the answer likely varies by specialty and patient population. The regulatory framework for AI-assisted clinical documentation varies between GCC states and is in active development in several of them; the framework proposed here anticipates rather than reflects the settled regulatory position. Long-term outcomes on downstream data quality, coding accuracy, and clinical decision support quality remain open.

We also flag a structural question. The framework as stated assumes that the AI system operates as an assistant to the physician who retains full editorial and clinical authority. As models improve, pressure will mount to allow autonomous documentation in low-stakes encounters. That is a defensible direction but requires a different framework than the one presented here, and the transition point should be an object of research rather than a commercial decision.

7. Conclusion

Clinical documentation AI in GCC healthcare is not a translation problem. It is a system-design problem with four load-bearing requirements: Arabic medical language coverage with dialect handling, sovereign hosting, standards-compliant EMR integration, and workflow-native capture. The current generation of English-first clinical AI systems fails on at least the first two of these when transplanted into the Gulf without adaptation. The field observations reported here suggest that when the framework is satisfied, physician acceptance and time-savings are attainable, but the responsible deployment path treats the AI as an assistant to a clinician who remains accountable for the record.

Further work is required in three directions: on dialect coverage adequacy, on outcome measurement across a larger site sample, and on the regulatory framework under which autonomous documentation, if ever appropriate, could be introduced. INFINITEWARE welcomes correspondence from clinicians, hospital administrators, and researchers working on any of these questions.