MedDeviceGuideMedDeviceGuide
Back

Saudi SFDA MDS-G27: Digital Health and Wellness Device Regulation

A comprehensive guide to Saudi Arabia's SFDA MDS-G27 (2025) regulation on digital health. Understand the boundary between medical devices and wellness software.

Ran Chen
Ran Chen
Global MedTech Expert | 10× MedTech Global Access
Published 2026-06-21Last reviewed 2026-06-216 min read

The digital health market in the Kingdom of Saudi Arabia (KSA) is expanding rapidly, driven by the government's Vision 2030 healthcare transformation goals. To govern this complex sector, the Saudi Food and Drug Authority (SFDA) has established a dedicated regulatory framework. A cornerstone of this framework is the guidance document MDS-G27 (Guidance on Digital Health Products), first issued on August 11, 2025 (Version 1.0, reference MDS-G-027-V1/250811).

[!NOTE] Scope note: This article is a dedicated deep dive into MDS-G27's product-qualification rules and classification tables. For a side-by-side comparison of Saudi digital-health rules with the UAE (EDE), Turkey (TITCK), and Israel, see our MENA digital health and AI medical device regulation guide.

This guide details the scope of MDS-G27, the criteria for qualifying digital health software as a medical device versus a general wellness product, and the compliance requirements for manufacturers seeking market entry in KSA.


Regulatory Scope of MDS-G27

MDS-G27 applies to a broad spectrum of digital health technologies. Issued under the authority of the Law of Medical Devices (Royal Decree No. M/54), the guidance covers nine key product categories:

  1. Software as a Medical Device (SaMD): Standalone software intended for medical purposes.
  2. Mobile Health Applications (mHealth Apps): Mobile apps designed for health monitoring, diagnosis, or treatment.
  3. Digital Therapeutics (DTx): Software delivering evidence-based therapeutic interventions.
  4. Health Information Technology (HIT): Administrative and hospital systems (EMRs, PACS).
  5. Telemedicine: Software enabling remote clinical services.
  6. Wearable Devices: Sensors and wearables capturing physiological data.
  7. Virtual Reality & Augmented Reality (VR/AR): Immersive software for therapeutic, diagnostic, or surgical navigation.
  8. Artificial Intelligence and Machine Learning (AI/ML): Algorithms operating on clinical data.
  9. General Wellness Devices: Software and hardware targeting general fitness and health preservation.

The Red Line: Medical Device vs. General Wellness

The most critical regulatory task for a software developer in KSA is determining whether their product qualifies as a regulated medical device (requiring an MDMA marketing authorization) or a general wellness device (subject to lighter post-market controls).

Digital Health Medical Device

A digital health product qualifies as a medical device if its intended use—as defined in labeling, instructions for use (IFU), or promotional materials—covers any of the following purposes:

  • Diagnosis, prevention, monitoring, treatment, or alleviation of a disease, injury, or disability.
  • Investigation, replacement, modification, or support of anatomy or a physiological process.
  • Supporting or sustaining life.
  • Controlling or assisting conception.

General Wellness Device

A product qualifies as a general wellness device if it meets either of the following:

  1. It makes a general wellness claim unrelated to any specific disease or medical condition (e.g., tracking daily step count, managing sleep hygiene).
  2. It makes a wellness claim referencing a chronic disease (e.g., Type 2 diabetes, high blood pressure, or coronary heart disease) solely regarding living well with that condition or mitigating its impact on well-being, without claiming to diagnose, prevent, cure, or treat the disease.

Categorization & Examples Under MDS-G27

The SFDA document outlines specific criteria for several rapidly emerging digital categories:

1. Software Driving or Influencing Hardware

Standalone software that drives or influences a physical medical device is qualified based on its function:

Scenario Qualification KSA Regulatory Implication
Software drives/influences a hardware medical device and has an independent medical purpose. SaMD Regulated independently as a standalone medical device.
Software drives/influences a hardware medical device but has no independent medical purpose. Accessory Regulated as an accessory to the parent medical device.
Software is solely used to operate or control a hardware device without contributing medical functionality. Not SaMD Regulated only as an accessory if it is intended to assist the device's basic mechanical control.

Source: SFDA MDS-G27, Section 1.2.1 (Table 1).

2. Telemedicine Software

Telemedicine is classified into three domains:

  • Tele-collaboration: B2B communication between healthcare professionals (e.g., case referral software).
  • Tele-treatment: Remote delivery of care (e.g., digital diagnostics platforms, robotic surgery controls).
  • Tele-monitoring: Remote collection of patient data.
  • Example: A remote diagnostic platform allowing radiologists to interpret DICOM images is a regulated medical device. A general administrative booking portal is not.

3. Wearable Devices

MDS-G27 splits wearables into two functional classifications:

  • Skin-based wearables: Non-invasive contact sensors (e.g., continuous ECG patches, wearable thermometers).
  • Biofluid-based wearables: Sensors analyzing body fluids such as sweat, saliva, tears, or urine for biomarkers (e.g., sweat-based glucose monitors, tear-analyzing smart contact lenses).
  • Note: If a consumer smartwatch contains an algorithm designed to detect atrial fibrillation (irregular heart rhythm) and alert the user, the AFib algorithm itself is regulated as medical device software, even if the watch hardware is sold as a general consumer product.

4. Virtual and Augmented Reality (VR/AR)

  • Regulated: VR/AR software used for intraoperative navigation, surgical planning, or non-pharmacological pain management therapy.
  • Non-Regulated: Immersive software used solely for medical student education, general wellness, or anatomical illustration.

AI/ML Technology Requirements

For digital health products utilizing AI/ML, the SFDA mandates a robust risk-based validation protocol. Developers must document:

  1. Verification and Validation (V&V): Testing algorithms against diverse, high-quality clinical datasets to prove performance accuracy.
  2. Data Governance: Enforcing data integrity, traceability, and patient privacy (complying with KSA data protection laws).
  3. Explainability: Providing documentation on how the algorithm processes inputs, its limitations, and potential demographic biases.
  4. Human Oversight: Clearly defining the role of the healthcare professional to prevent automated clinical decisions without human intervention.
  5. Change Management: Establishing procedures for post-market algorithm updates, re-validation, and documentation of drift.

The Regulatory Path to Compliance

If your digital health product qualifies as a medical device under MDS-G27, you must obtain a Medical Devices Marketing Authorization (MDMA) from the SFDA before placing it on the KSA market.

Compliance involves aligning with multiple companion regulations:

  • MDS-REQ 1: Requirements for Medical Devices Marketing Authorization.
  • MDS-G23: Guidance on Software as a Medical Device.
  • MDS-G010: Guidance on AI/ML-based medical devices.
  • MDS-G38: Guidance on Pre-Market Cybersecurity of Medical Devices.
  • MDS-REQ 10: Requirements for Inspections and Quality Management System, aligned with ISO 13485.

Foreign manufacturers must appoint a local Authorized Representative (AR) in Saudi Arabia to manage the MDMA submission via the SFDA's online portal.

Disclaimer: This article is for educational and informational purposes only. It does not constitute legal, regulatory, or quality system advice. Manufacturers should consult official SFDA texts or an authorized consultant before planning a registration in Saudi Arabia.