Marketing authorisation tells a manufacturer what to prove. It does not tell a hospital what to verify.
In June 2026 the SFDA granted marketing authorisation to a smartphone application that reads heart rate, oxygen saturation and blood pressure from a short facial video. It was the first regulator in the world to clear a tool of that kind. The decision followed a review of the technical documentation and the clinical evidence, and it carried one careful line: the application is not a standalone diagnostic tool and is not for emergency or critical care use.
That line is a scope statement. It tells you what the tool is for. It does not tell a hospital in Riyadh or Jeddah whether to deploy it, on which patients, wired into which workflow, or how anyone would notice when it had drifted out of calibration. The SFDA answered the question it exists to answer: may this be placed on the Saudi market? The second question — should we switch it on here, on our patients, next week — was never on the SFDA's desk. It was never meant to be.
The SFDA has built one of the most developed manufacturer-side regimes for clinical AI anywhere. What it has not built, because it was never the SFDA's job to build, is the thing a procuring hospital needs the morning after authorisation: a way to check whether an authorised tool is suitable for its own population, its own alert burden, and its own clinical governance. Marketing authorisation and procurement readiness are two different gates. Saudi Arabia has marked the first one well. The second is still unmarked, and the buyer is standing in front of it alone.
What these two documents actually are
The relevant instruments are MDS-G010 (Guidance on AI and ML technologies based Medical Devices, 2022) and the newer MDS-G53 (Guidance on Review and Approval of AI and Big Data Based Medical Devices). Both are addressed to manufacturers. Both set out what a developer must submit to obtain Medical Device Marketing Authorization and place a tool on the market in the Kingdom. MDS-G53's first half handles classification — whether a piece of software is a medical device at all, and at what risk class. Its second half sets review and approval expectations. MDS-G010 goes deeper on clinical evaluation, risk management and change notification.
A legal analysis by Barry Solaiman (Asian Bioethics Review, 2024) reads MDS-G010 as a considered assembly of international best practice, with close congruence to the FDA and IMDRF approaches, built on top of the SFDA's existing regulatory architecture. That is a fair reading. It is also the point. These documents tell a manufacturer what to prove to sell a tool in Saudi Arabia. They do not tell a hospital what to verify before using one. The word procurement does not appear. The purchasing institution is not an actor in the text.
None of that is a defect. A drug regulator does not write the hospital's formulary decisions either. But clinical AI has a feature that pharmaceuticals do not: the same authorised tool behaves differently in different buildings, on different populations, under different alert thresholds, and it degrades quietly over time. Authorisation is a snapshot taken once, centrally. Deployment is a moving target owned locally. The gap between them is where patients meet the tool.
What the guidance does well
Credit first, because the SFDA has earned it.
The scope test is drawn by intended use. If a developer intends a tool for detection, diagnosis, monitoring, treatment or management of a condition, it is a medical device under SFDA control. There is no clinical decision support carve-out of the kind that let the Epic Sepsis Model operate in a regulatory grey zone in the United States, where the vendor leaned on a non-device CDS exemption that was never reconciled with how the tool was actually used at the bedside. On the SFDA's scope test, a sepsis-prediction tool of that type is a device, and it faces the device requirements. That closes a door other regulators left open.
The clinical evaluation requirements follow the IMDRF model: a valid clinical association, analytical validation, then clinical validation in the target population. The guidance asks for outcomes that matter to patients and clinicians, not only sensitivity, specificity and AUROC. And it asks for the right comparison: clinician performance with the tool against clinician performance without it, rather than the tool against the clinician alone. That second point is the one most vendors get wrong and most buyers forget to ask for. The SFDA has it in writing. Where these requirements fall short is not in what they ask, but in who they ask it of.
On population validity, the guidance is ahead of most of its peers. It requires the reference dataset to reflect the prevalence of the target condition, to be sourced from several centres for heterogeneity, and to correspond to the demographic and socio-economic profile of the target region. It asks for subgroup analysis across demographics, geography and disease subtype. And it requires manufacturers to locally validate tools that were developed and approved in other jurisdictions. A regulator that already names the population-transfer problem is a regulator worth taking seriously.
On the period after go-live, the guidance requires a post-market surveillance plan, periodic safety update reports, continuous real-world monitoring of safety and performance, and adverse-event reporting to the SFDA. It defines locked and adaptive models and it operates a change-notification regime through the GHAD system, with significant changes reported within ten days. The SFDA is not treating an AI tool as a static object that stops mattering once it ships.
This is a serious framework. The gaps that follow sit on the buyer's side of the gate, in questions the guidance was never designed to answer.
Where the guidance stops and the buyer starts
Take the domains a hospital has to score before it deploys, and lay the guidance against them.
Population validity is the clearest case. The SFDA requires the dataset to correspond to the target region. The target region is Saudi Arabia. A specific hospital is not Saudi Arabia. A tertiary centre with a large expatriate catchment is a different denominator from a district hospital serving a settled national population, and both differ from the outpatient sample a tool may have been validated on. The national average the SFDA certifies against is real, and it is not the patient in front of you. Worse, the manufacturer's local validation is submitted to the SFDA, not published to the buyer. A hospital reading the authorisation cannot see whether that validation included patients like theirs. Authorised for Saudi Arabia. Not yet proven for your catchment. On my rubric this is where the Population Validity interlock fires: absent population-specific evidence for the actual deployment setting, the recommendation is to withhold deployment until that evidence exists, however strong the tool looks elsewhere.
Operational performance is a local fact the authorisation cannot carry. A sepsis model that performs acceptably in validation can still generate an alert every few minutes in an emergency department whose prevalence and triage thresholds differ from the validation site. The Epic Sepsis Model is the standing example: high alert volume, a false-positive burden that trained clinicians to override it, and adoption that decayed inside a year. The SFDA asks for real-world integration testing and clinician-with-versus-without evidence, which helps. It cannot tell a particular hospital what alert burden the tool will produce on its own case mix. That number only appears after go-live, in that building, and someone local has to be watching for it.
Change control is a genuine structural gap, not a matter of emphasis. MDS-G010 operates change notification: the manufacturer tells the SFDA when a model changes. It references the FDA's predetermined change control concept in its further reading, but it does not itself run a predetermined change control plan. So an adaptive model can update, the manufacturer can notify the regulator, and the hospital depending on that model may not know its behaviour shifted underneath it. A buyer needs a contractual right to be told when a deployed model changes, and a re-evaluation trigger that fires when it does. The authorisation gives the buyer no such right.
The post-market obligation sits on the wrong actor for the buyer's purposes. The SFDA requires the manufacturer to monitor and report. It does not give the hospital a protocol for its own monitoring, and the manufacturer's surveillance is not visible to the buyer in real time. The most dangerous window for a clinical AI tool is months six to eighteen, when drift sets in and adoption quietly decays. That window is the hospital's to police. A buyer needs its own audit schedule — a go-live validation, an early-adoption review, a first full audit at six months, an annual re-score, and quarterly monitoring in between — because the regulator's reporting line runs from the vendor to the SFDA, not to the ward.
Islamic bioethics compatibility needs care, and I will state its limits plainly. MDS-G010 treats ethics through the international risk-management lens it inherits from ISO 14971, IMDRF and WHO. It does not adapt its evaluation criteria to the ethical framework a Saudi institution operates under. This does not mean Saudi Arabia lacks bioethics governance. The National Committee of Bioethics at KACST has set national standards since 2001, and every institution conducting research on human subjects is required to operate a local ethics committee under its supervision. It means the marketing authorisation does not certify that a tool's embedded logic for triage, futility or resource allocation is transparent to, or configurable for, a local ethics committee. That verification stays with the institution. My rubric does not adjudicate the ethics. It checks something narrower and answerable: whether the vendor supplies a plain-language account of the tool's decision logic and an override protocol with logging, so the people whose job it is to make that judgement can actually read the tool. A committee cannot rule on logic it cannot see.
The remaining domains — clinical evidence quality, workflow integration, data governance and sovereignty, implementation maturity — follow the same pattern. The SFDA sets what the manufacturer must demonstrate to the regulator. The buyer still has to verify what the tool does inside its own systems, on its own data-residency terms, at its own level of integration readiness. Authorisation is evidence the buyer should weigh. It is not the evaluation.
Two gates, and only one is marked
A tool can clear every SFDA requirement and still be the wrong tool for a given department, because suitability is a local property and authorisation is a central act.
The second gate scores a tool across the domains a hospital actually carries the risk on: the quality and independence of the clinical evidence, population validity for this setting rather than the nation, the operational alert burden under this case mix, workflow fit, regulatory and data-sovereignty compliance, implementation maturity, and the ethical legibility of the tool to the committee that must sign it off. It applies one rule the composite score cannot override: if any single domain is critically weak, the recommendation is do not proceed, regardless of how strong the others are. You do not average away a red flag. That is how clinical decision rules have always worked, and it is how procurement decisions for clinical AI should work too.
The SFDA has done the harder, earlier work. Most regulators are still drafting their front gate. The buyer-side gate is the complement that begins where the authorisation ends.
Authorisation answers whether a tool may be sold in the Kingdom. It does not answer whether it should be switched on in your department on Tuesday morning. That question still belongs to someone in the building.
Sources: SFDA MDS-G010, Guidance on AI and ML technologies based Medical Devices (2022); SFDA MDS-G53, Guidance on Review and Approval of AI and Big Data Based Medical Devices; Barry Solaiman, "Regulating AI-Based Medical Devices in Saudi Arabia," Asian Bioethics Review (2024); Arab News, SFDA marketing authorisation for AI-powered medical application (June 2026).