Is Your Digital Health Product a Medical Device in Saudi Arabia?

An app is not a medical device because it appears in a health category, and a wellness label does not automatically place it outside SFDA scope. MDS-G027 ties qualification to the manufacturer's intended purpose and to what the software does for an individual patient or user. The key questions are whether it diagnoses, monitors, treats or supplies information used in a clinical decision.

The analysis should start with the claim, function and output rather than the technology. A simple AI model can be SaMD when it performs a medical purpose, while a large platform may remain administrative if it only schedules, communicates or stores information without medical analysis. The framework below moves from qualification to classification, evidence and change control.

1 Medical purpose is the boundary

MDS-G027 explains that a digital product qualifies as a medical device when it is intended for purposes such as prevention, detection, diagnosis, treatment, monitoring or management of a medical condition. Intended use is evidenced through labeling, specifications, instructions and accompanying material. The app-store page, sales deck, user interface and clinician training therefore need review as one claim system. A loose claim in one channel can contradict the regulatory file.

SaMD performs a medical purpose without being part of medical-device hardware. Embedded software that operates the hardware is SiMD and falls outside the direct scope of MDS-G027. Independent software that influences hardware may be SaMD if it has its own medical purpose, or an accessory if it supports the device without an independent medical purpose. This decomposition comes before class.

2 A health function is not always a medical function

MDS-G027 places general education, patient-provider communication and population analytics that do not target individual diagnosis or treatment outside SaMD examples. Administrative HIT functions such as appointments, billing and documentation, or the transfer and display of data without analysis, are also generally non-device. Adding interpretation of a laboratory result, a diagnostic suggestion or a clinical alert can bring a specific module into medical-device scope.

To turn this analysis into a product-specific plan, review Technical File and Regulatory Readiness Review and the related regulatory insight.

For a multi-module platform, calling the whole product health IT or an AI platform is inadequate. Map each module, its data, output, recipient and the action it drives. MDS-G027 allows non-medical modules to remain outside the submission where their separation and non-medical function are clearly documented, while modules that independently qualify as devices are submitted for regulatory review.

3 Initial qualification tree

4 SaMD qualification is followed by class

Once software qualifies as a device, the MDS-REQ 1 rules apply. Rule 11 generally places software supplying information for diagnostic or therapeutic decisions in Class B, rises to C where a wrong decision may cause serious deterioration or surgical intervention, and to D where it may cause death or irreversible deterioration. Physiological monitoring may also rise when changes could create immediate danger.

The scenario cannot be selected from a short claim. Document the condition and severity, patient, user, automation level, human review, time available to intervene and role of the output in the clinical pathway. Optional information reviewed by a clinician among several inputs differs from an automated therapy control or a decisive output presented without meaningful review. Those facts form the classification rationale.

5 AI expands the evidence record

For AI or ML medical products, MDS-G027 identifies focus areas that include verification and validation using diverse high-quality data, data governance and traceability, transparency about limitations and bias, risk management including cybersecurity and privacy, human oversight, and controls for updates, revalidation and post-market performance. These points need traceability from claims and risks to datasets and tests.

Before launch, describe dataset provenance, population representation, separation of training and validation data, subgroup performance, missing-data handling and use limitations. After launch, define complaint linkage, drift monitoring, revalidation triggers, rollback and version release. Writing human in the loop is not evidence of oversight unless the interface and workflow show what the clinician sees and how intervention occurs.

6 Change control starts before the first release

A change to an input, output, population or threshold can alter intended purpose, performance or risk. MDS-G027 expects procedures for updates, revalidation, performance monitoring and documentation of algorithm changes. Model-weight updates, retraining and new integrations should therefore enter the regulatory change process rather than remain isolated engineering releases.

Create a shared release gate across product, clinical, quality and regulatory teams. The record should describe the change, affected claim, new data, regression results, human-factors and cybersecurity impact, and whether labeling, the MDMA file or UDI-DI requires assessment. This gives development a defined route to release without allowing a clinical or risk change to bypass regulatory review.

Keep two connected records: a software bill of materials and configuration record showing what was released, and a regulatory decision record explaining why the claim, class and authorization scope remain valid. If a complaint or subgroup performance issue appears, the team can trace it to the version, data and known limitations at release and decide whether the correction is technical only or needs regulatory action.

References: [1] [2]