Is a Hospital Patient App a Medical Device in Saudi Arabia? What SFDA's Digital Health Guidance Means for Your App Roadmap
Short answer: Under the SFDA Guidance on Digital Health Products (MDS-G27, version 1.0, August 2025), software is treated as a medical device when its intended use is medical (prevention, diagnosis, treatment, monitoring or management of a condition) and it does more than store, communicate or display data. Booking, billing and record display are generally outside scope; analysis that informs individual patient care is not. [VERIFY WITH BRAND]
Key takeaways
- Classification follows the manufacturer's intended use, as shown in labelling, specifications and instructions for use, not the app's name or screen design.
- The guidance excludes software intended solely for administrative or communication support, and software designed exclusively to store, transfer, convert or display medical data.
- Features that analyse or interpret patient data, or give patient-specific recommendations, are candidates for medical-device status and need a regulatory assessment.
- Write an intended-use statement for every feature release, and keep it consistent with marketing copy.
- This article is an operational reading of public guidance, not legal advice or an SFDA ruling. [VERIFY WITH BRAND]
On this page
Why hospital IT and product teams are asking this now
Most Saudi hospital groups started their patient apps as a digital front door: book, pay, receive results, get reminded. That scope is administrative. The question changes the moment a roadmap adds a symptom checker, a blood-pressure alert or an AI-generated care suggestion. At that point the app begins to look less like a booking tool and more like software that supports clinical decisions.
The Saudi Food and Drug Authority published its Guidance on Digital Health Products (MDS-G27) in August 2025. It covers nine categories: software as a medical device (SaMD), mHealth apps, digital therapeutics, health IT, telemedicine, wearables, VR/AR, AI/ML and general wellness devices. It is written for manufacturers seeking Medical Devices Marketing Authorization (MDMA) and for end users. For a hospital, that second audience matters: you are often both the buyer and the party that configures how the product is used.
The test SFDA applies: intended use and what the software does with data
Two ideas carry most of the weight in the guidance.
First, a medical purpose. The software must be intended for purposes such as prevention, diagnosis, treatment, monitoring or management of a condition. SFDA's own FAQ states the principle plainly: software is a medical device if its intended use meets any of the purposes in the device definition.
Second, what happens to the data. Software that goes beyond storage, archiving, communication or search, by analysing, interpreting or manipulating data for the benefit of an individual patient, becomes a candidate for device status.
Intended use is set by the manufacturer through labelling, specifications and instructions for use. That has a practical consequence for hospitals that commission or white-label an app: the words in your product brief, app-store description and sales deck can become evidence of intended use.
Where common patient-app features are likely to land
The table below applies the guidance's published exclusions to typical hospital app features. It is our inference from the guidance wording, not an SFDA determination. [VERIFY WITH BRAND]
| Feature | Likely position under MDS-G27 | Why |
|---|---|---|
| Appointment booking, admissions, billing | Generally outside device scope | Administrative or communication support only |
| Displaying lab results or records unchanged | Generally outside device scope | Designed exclusively to store, transfer, convert formats or display medical data |
| Secure patient-clinician messaging | Generally outside device scope | Does not analyse or interpret clinical data |
| Generic appointment and medication-time reminders | Generally outside device scope | The guidance treats reminders as non-device where they do not manage dosage or give drug-specific recommendations |
| General health education content | Generally outside device scope | No patient-specific diagnosis, treatment recommendation or decision support |
| Dose adjustment prompts, drug-specific advice | Needs regulatory assessment | Moves beyond a plain reminder |
| Symptom triage that suggests a diagnosis or urgency | Needs regulatory assessment | Interprets patient data to inform care |
| Home-monitoring thresholds that trigger clinical alerts | Needs regulatory assessment | Monitoring and interpretation of patient data |
| AI risk scores shown to clinicians | Needs regulatory assessment | May also engage SFDA's AI/ML guidance (MDS-G10) |
The guidance also points to related documents for products that do qualify: MDS-G23 (SaMD), MDS-G10 (AI/ML-enabled devices) and MDS-G38 (pre-market cybersecurity). Teams planning analytics features should read those alongside MDS-G27.
A planning scenario: the six-hospital group adding blood-pressure alerts
Illustrative scenario, not a customer case. Imagine a six-hospital group in the Eastern Province whose patient app handles booking, payments and result viewing. The innovation team proposes adding home blood-pressure entry with an automatic "contact your doctor" alert when a reading crosses a threshold.
The booking and results features sit in the administrative category. The threshold alert does not: it interprets a patient's measurement and prompts a clinical action. Before development starts, the group should do four things:
- Write an intended-use statement for the alert feature: who it is for, what it does, what it does not do.
- Ask the vendor or in-house team whether the feature is designed to be a medical device, and who the legal manufacturer would be.
- Request an SFDA assessment route or classification opinion before launch, rather than after.
- Decide whether the alert goes to a clinician queue with human review, which changes the clinical-governance design even where classification is unchanged. HOLD — expert review
The cheaper route is often a staged roadmap: ship administrative features now, and gate analytic features behind a regulatory decision.
Building the habit: an intended-use register
The teams that avoid surprises treat classification as a living artefact, not a one-time check.
- One line per feature. Keep a register with feature name, intended use, data inputs, who sees the output, and the regulatory position taken.
- Align marketing with the register. If a sales deck claims the app "monitors" or "detects" something, the register should explain why the feature is or is not a device.
- Re-review on change. A reminder that begins suggesting dose timing, or a display that adds a risk colour, can change the analysis.
- Contract for it. Ask vendors who holds the marketing authorization where one is needed, and how changes are notified.
- Keep privacy in view. Classification is separate from data protection; PDPL obligations apply regardless of device status. See our guide on data localisation questions to ask health SaaS vendors.
How this fits a unified hospital platform
A white-label platform that covers booking, communication, reminders and reporting is mainly an administrative and communication layer. CareSync Network is positioned for that layer across multi-branch hospitals; any monitoring or analytics modules would be assessed feature by feature against the guidance. [VERIFY WITH BRAND] For related reading, see how a hospital app should be positioned next to Sehhaty and what to test before go-live in our patient app acceptance-testing guide.
FAQ
Is a hospital patient app a medical device in Saudi Arabia?
Not automatically. Under SFDA's MDS-G27, the answer depends on intended use. An app limited to booking, billing, messaging and displaying records is generally treated as administrative or communication support, while features that analyse or interpret patient data for patient care may qualify as medical-device software. [VERIFY WITH BRAND]
Does an appointment booking app need SFDA registration?
The guidance describes software intended solely for administrative or communication support, such as booking, admissions and billing, as not a medical device. Confirm the position for your exact feature set with SFDA or regulatory counsel. [VERIFY WITH BRAND]
What is MDMA?
Medical Devices Marketing Authorization is the route by which a manufacturer obtains authorization to market a medical device in the Kingdom. MDS-G27 refers manufacturers of qualifying digital health products to the MDS-REQ 1 requirements; it does not itself set out the application procedure or timelines.
Are medication reminders regulated as medical devices?
The guidance treats a medication reminder as non-device where it operates without managing dosage or providing drug-specific recommendations. Adding dosing logic or drug-specific advice changes the analysis.
Who is responsible when a hospital white-labels an app?
The guidance frames classification around the manufacturer's intended use. Contracts should state who the legal manufacturer is, who holds any authorization, and how feature changes are notified. Legal counsel should confirm responsibilities. [VERIFY WITH BRAND]