Is Your Health App a Medical Device? CDSCO's Medical Device Software Guidance Explained for App Builders

You have an idea for a health app. Maybe it reads blood pressure from a Bluetooth cuff. Maybe it uses AI to flag abnormal ECGs, or helps patients with diabetes manage their condition between visits.

Then someone asks a question that stops the meeting: "Is this a medical device? Do we need a licence?"

For years, the honest answer in India was "it depends", with very little written guidance. That has changed. The Central Drugs Standard Control Organisation (CDSCO) has published a detailed Guidance Document on Medical Device Software (Doc. No. CDSCO/MD/GD/MDSW/01/2026). This guide explains, in plain language, what it means for hospitals, doctors and founders building health apps, and what to plan before you write the first line of code.

Quick answer: Under the Medical Devices Rules, 2017, software is a medical device when its intended use is medical, such as diagnosing, screening, monitoring, treating or predicting a disease, or controlling a medical device. Platform doesn't matter: mobile apps, AI tools, cloud and SaaS software can all qualify. Pure wellness and fitness apps, and software used only for appointments, billing, storage or communication, are generally outside the rules. Regulated software is placed in risk Class A, B, C or D, which decides the licence route and evidence required.

This article is general information, not legal or regulatory advice. Always check the current CDSCO documents and take professional regulatory advice for your product.

What CDSCO published, and why it matters now

The Hindu reported on 29 July 2026 that CDSCO had issued the guidance to help manufacturers, importers, innovators and researchers prepare applications. CDSCO stressed that it reflects current practice under the Medical Devices Rules, 2017 (MDR-2017) and isn't a new regulatory control. In other words, the rules already applied. Now they are spelled out.

That matters because health apps are moving fast in India: AI tools for screening, remote monitoring, patient apps for hospitals and digital programmes for chronic conditions. The guidance gives everyone the same reference point, from the founder pitching investors to the hospital buying a tool.

When is software a medical device?

The guidance says it plainly: not all software used in healthcare is medical device software (MDSW). What decides it is the intended use, as shown in your labelling, instructions, website and promotional material.

Software that is covered

The guidance gives practical examples of software that is regulated, including:

1. An app that connects by Bluetooth to a blood pressure cuff to track blood pressure for medical purposes
2. Computer-aided detection software that analyses X-ray images or ECGs
3. An AI/ML tool for triage or screening of cancer lesions
4. A connected platform that works with devices such as smart glucometers to track chronic conditions and offer AI-driven interventions
5. A digital therapeutics platform intended to slow the progression of conditions such as Type 2 diabetes or hypertension
6. Apps or cloud software that control or adjust a medical device, by cable, Bluetooth or Wi-Fi

Software that is generally not covered

The guidance also lists software that is not medical device software, such as:

1. Hospital and clinical information systems used only for admissions, appointments, insurance, billing and storing or transferring patient information
2. General communication systems, including email and video calling
3. Software that only transfers, stores, archives, converts or compresses data
4. Software only for medical teaching or training

That's useful news for hospitals. A typical appointment app, patient portal or hospital management software for scheduling and billing generally stays outside the rules. But the guidance notes these systems can come under MDR-2017 if they add medical functions such as image analysis, clinical decision support, screening or real-time patient monitoring.

The general wellness line

General wellness software, which encourages a healthy lifestyle or tracks parameters for fitness, is outside MDR-2017. The catch is in the wording. The guidance says wellness software shouldn't refer to diseases, disorders or pathological conditions, and software that measures values for screening, diagnosis, monitoring, alerting or managing a condition isn't wellness software.

So "track your daily steps" is wellness. "Alert you when your readings suggest hypertension" is very likely a medical purpose.

Key takeaways

1. Intended use, not technology, decides whether your app is regulated.
2. Scheduling, billing, storage and video-calling software is generally outside the rules.
3. One disease claim in your app store listing or ads can turn a wellness app into a medical device.

Risk classes A to D: where would your app sit?

MDR-2017 has four risk classes: Class A (low), Class B (low-moderate), Class C (moderate-high) and Class D (high). Software that drives a hardware device generally takes the same class as that device.

For standalone software, the guidance uses two questions: how important is the information to the healthcare decision, and how serious is the condition?

1. Critical. Treats or diagnoses: Class D. Drives clinical management: Class C. Informs clinical management: Class B.
2. Serious. Treats or diagnoses: Class C. Drives clinical management: Class B. Informs clinical management: Class A.
3. Non-serious. Treats or diagnoses: Class B. Drives clinical management: Class A. Informs clinical management: Class A.

Two details are easy to miss:

1. Software used by non-clinical users (such as patients) in a serious condition, without specialist support, may be treated as used in a critical situation, which raises the class.
2. If more than one rule applies, the higher class applies.

Before applying, CDSCO expects you to check its published risk classification lists. If your software isn't covered, you can request a classification through the CDSCO medical devices online portal.

Licences: who you deal with

The guidance sets out the route from prototype to market. In simple terms:

1. Test licence: to make or import limited quantities for testing, evaluation, demonstration or clinical investigation (not for sale). For software, quantity can be stated as installations or deployments.
2. Clinical investigation: needed for investigational software with no predicate; exemptions are possible in some cases.
3. Manufacturing licence: Class A and B are handled by the State Licensing Authority; Class C and D by the Central Licensing Authority.
4. Import licence: handled centrally for all four classes.
5. Class A exemption: non-sterile, non-measuring Class A devices are exempt from licensing but must be registered.

The exact forms, fees and documents are listed in the guidance and MDR-2017. This is where a qualified regulatory consultant earns their fee.

What changes in how you build the app

Here is the part founders often underestimate. If your app is medical device software, the guidance expects the build itself to be documented and controlled. Expect to plan for:

A clear intended-use statement

Describe the condition, patients, users, setting, inputs, outputs and the software's role: whether it informs, drives or makes decisions, and whether a clinician stays in control.

A quality management system for software

The guidance expects lifecycle control covering requirements, design, source-code management, version control, release management and maintenance. It refers to standards such as ISO 13485, ISO 14971 and IEC 62304.

Cybersecurity and a software bill of materials

Secure-by-design development, threat modelling for connected and cloud software, and a software bill of materials (SBOM) listing third-party and open-source components so vulnerabilities can be tracked.

Version tracking and change control

Every deployed version must be traceable. Major changes need approval and minor changes need notification. AI products can use an Algorithm Change Protocol to plan anticipated model updates.

Indian clinical evidence and usability

Usability validation should reflect Indian clinical workflows, languages and infrastructure. Where AI models are trained or validated outside India, expect to justify how they perform here.

ABDM and data protection

Where the software handles patient health information, the guidance says it should align with the Ayushman Bharat Digital Mission framework where applicable: interoperability, consent-based access and secure exchange. Patient data also falls under the DPDP Rules.

Key takeaways

1. Regulated apps need documented requirements, design, testing and version control from the start.
2. Plan cybersecurity, an SBOM and change control for every release, especially for AI models.
3. Retrofitting this documentation after launch is slower and costlier than building it in.

A practical checklist before you build

1. Write your intended use first. Keep marketing copy, app store text and investor decks consistent with it.
2. Decide: wellness, admin or medical? Remove disease claims if you want to stay a wellness product.
3. Estimate the risk class with the grid above, then confirm it with a regulatory expert.
4. Choose a development partner that can work with documented requirements, version control and test records.
5. Plan data protection and ABDM integration early, not at launch.
6. Budget time for testing, evidence and approvals in your roadmap.

If you're planning an AI product, our guide to healthcare AI app development in India covers the national AI frameworks, and our hospital patient portal app guide covers patient-facing features.

How Pengwin Solutions helps

Pengwin Solutions designs and builds healthcare apps, web platforms and patient experiences, with design, development and marketing in one team. For health apps that may fall under CDSCO rules, we:

1. Help you frame features and claims so the product matches its intended use
2. Build with documented requirements, version control, test records and secure-by-design practices
3. Design accessible, multilingual interfaces that fit Indian clinical workflows
4. Work alongside your regulatory consultant so documentation is ready when it's needed

We don't replace regulatory advice. We build software that makes the regulatory work easier. Explore our app and custom software development, UI/UX design and healthcare digital services.

Frequently asked questions

Is every health app a medical device in India?

No. Under CDSCO's guidance, software is a medical device only when its intended use is medical, such as diagnosis, screening, monitoring, treatment or prediction of disease, or control of a medical device. Wellness and purely administrative apps are generally outside the rules.

Is a doctor appointment or telemedicine app a medical device?

Software used only for appointments, billing, storing or transferring patient information, or general video calling is generally not medical device software under the guidance. Adding medical functions such as diagnosis support or remote monitoring can change that.

Are fitness and wellness apps regulated by CDSCO?

General wellness software that promotes a healthy lifestyle or tracks parameters for fitness is outside MDR-2017, provided it doesn't refer to diseases or disorders or measure values for screening, diagnosis, monitoring or managing a condition.

How is medical device software classified?

Into Class A, B, C or D under MDR-2017. For standalone software, the class depends on how serious the condition is and whether the software treats or diagnoses, drives clinical management or informs clinical management.

Does AI software need CDSCO approval?

AI and machine-learning software is covered when its intended use is medical. It then follows the same risk classification and licensing route, with extra expectations on data, validation, monitoring and managing algorithm changes.

Who issues licences for medical device software?

Manufacturing licences for Class A and B are handled by the State Licensing Authority, and Class C and D by the Central Licensing Authority. Import licences for all classes are handled centrally. Some Class A devices need only registration.

Build your health app on the right foundation

Call +91 90326 18332, email hello@pengwinsolutions.com, or contact Pengwin Solutions to plan a health, AI or patient app that is designed, documented and built to the standard your product needs.