On 21 July 2026, India's Central Drugs Standard Control Organisation (CDSCO) released the final Guidance Document on Medical Device Software (Doc No. CDSCO/MD/GD/MDSW/01/2026), issued through a Medical Devices Division circular. The circular advises all State and Union Territory licensing authorities and all stakeholders to refer to the document when applications are prepared and reviewed under the Medical Devices Rules, 2017 (MDR 2017).
The document closes a long-standing gap in India's digital health regulation. The October 2025 draft attracted wide comment; the final version answers the two questions every software company entering the Indian market asks: is my product a medical device at all, and if it is, what class is it and what will CDSCO expect in my file? This article walks through the final guidance in full: scope, the classification framework, the intended use statement, the specific expectations for AI and machine learning products, quality management, documentation, and post-market duties. It also covers what changed between the draft and the final version, because if your regulatory planning was built on the draft, parts of it now need revision.
One framing point before the detail. The document describes itself as reflecting current practice under MDR 2017, and states expressly that it should not be read as a new regulatory control on software. Consistent with that, it does not create a new licensing pathway. Software that qualifies as a medical device is licensed through the same MDR 2017 routes as any other device. What the guidance does is define which software falls inside the system, how it is classified, and what reviewers will expect to see in applications.
What counts as medical device software (MDSW)?
The guidance applies to any software that meets the definition of a medical device under MDR 2017, including software for in vitro diagnostic purposes. It uses the umbrella term medical device software, MDSW, and draws its boundary by function.
MDSW covers software intended for a medical purpose that either performs that purpose on its own, as standalone software, or forms part of a hardware medical device, or drives or influences the use of one. The guidance is explicit that the regulated population includes mobile applications, cloud and network based software, AI and machine learning based software, software interfaced with other medical devices or with general purpose hardware, and commercial off the shelf software, in each case where the software meets the medical device definition. The delivery model and the hosting environment have no bearing on regulatory status; the intended function determines it.
"Medical purpose" is defined broadly. It includes diagnosis, prevention, monitoring, treatment, or alleviation of disease or disorder; diagnosis, monitoring, treatment, alleviation of, or assistance for injury or disability; investigation, replacement, modification, or support of anatomy or a physiological process; supporting or sustaining life; disinfection of medical devices; and control of conception. The guidance extends the concept to mitigation and prediction of disease and pathological conditions, and it applies to software intended for use in humans or in animals. The inclusion of prediction matters: risk prediction tools that developers often assume sit safely in the wellness category can fall inside the definition when their output serves a clinical purpose.
What falls outside regulation?
The guidance is equally useful for what it excludes. Software intended solely for general wellness, fitness, education, or training, with no medical purpose, is outside MDR 2017. So is software limited to data transfer, storage, archival, formatting, or communication. Hospital information systems, laboratory information systems, and general purpose communication tools are outside scope where their functions do not independently serve a medical purpose.
The controlling principle is that exclusion is function specific, and never product specific. A hospital platform whose core is administrative can still contain one regulated function. The guidance gives the natural examples: image analysis offered as an aid to diagnosis, quantification of physiological parameters that feeds clinical decision making, or real time patient monitoring. If one module does any of those things, that functionality attracts regulation even though the surrounding product is exempt. For product teams the consequence is architectural as much as legal: knowing precisely which functions carry a medical purpose, and being able to describe and bound them, determines the size of your regulatory perimeter.
What changed from the October 2025 draft?
Three changes matter most for anyone whose planning was based on the draft.
First, the terminology moved. The draft was organized around the international SaMD and SiMD vocabulary: Software as a Medical Device for standalone products, Software in a Medical Device for embedded software. The final text drops those labels as its organizing vocabulary. It defines MDSW in two arms: software that performs a medical purpose without being part of a hardware device, which the document notes may also be referred to as standalone MDSW, and software that is part of a hardware medical device or drives or influences its use. The substance carries over, standalone software is still regulated on its own merits and embedded software is still tied to its parent device, but the two-label vocabulary is gone. If your dossier drafts, intended use statements, or classification rationales use SaMD and SiMD as their organizing terms, align them to the final document's language before filing.
Second, process got specific. Stakeholders had noted that the draft only loosely described how software products obtain permissions. The final guidance sets out the process for test and evaluation permissions and for standard commercial licenses, giving software manufacturers the same procedural visibility that hardware manufacturers have had. It also fixes the portal split in plain terms: test licence applications go through the National Single Window System (nsws.gov.in), and every other application, permissions, manufacturing and import licences, and registrations, goes through the CDSCO MD Online portal (cdscomdonline.gov.in).
Third, the Algorithm Change Protocol matured from concept to framework. More on that in the AI section below, because it is the most commercially consequential feature of the document for AI developers.
How is MDSW classified?
Classification follows the risk based structure of the First Schedule of MDR 2017, the same four classes that apply to all devices in India: Class A (low risk), Class B (low to moderate risk), Class C (moderate to high risk), and Class D (high risk). The class determines the licensing authority and the depth of review. For manufacturing licences, Class A and B sit with the State Licensing Authority, with the lowest risk Class A devices (non-sterile and non-measuring) on a registration route rather than licensing, and Class C and D with the Central Licensing Authority, meaning CDSCO itself. Import licences, test licences, and new-device permissions sit with the Central Licensing Authority for every class.
For software, the guidance establishes two classification mechanisms.
Software that drives or influences a hardware medical device takes the risk class of that hardware. Firmware controlling an infusion pump is classified with the pump. This rule is simple and absolute, and it means embedded software developers inherit their regulatory burden from the device they serve. The final text adds a commercial nuance worth knowing: embedded software supplied with its parent device can be licensed along with it as a component or accessory, while the same software sold separately from the hardware requires its own manufacturing or import licence.
Standalone MDSW is classified through a matrix that reads two questions against each other: how significant is the information the software provides for the healthcare decision, and how serious is the healthcare situation it addresses? The guidance defines the situation levels precisely. A critical situation is one where accurate or timely action is vital to avoid death, long term disability, or serious deterioration of health, or to mitigate impact on public health. A serious situation is one where accuracy is vital to avoid unnecessary interventions or long term irreversible consequences. A non-serious situation involves slow, predictable progression manageable with minor, largely non-invasive interventions. The guidance publishes the matrix itself. Reading significance of information against the healthcare situation: software whose output is used for treatment or diagnosis classifies as Class D in a critical situation, Class C in a serious one, and Class B in a non-serious one; software that drives clinical management classifies C, B, and A down the same three rows; and software that merely informs clinical management classifies B, A, and A. One note in the matrix bears directly on consumer health developers: standalone MDSW intended for non-clinical users in a serious situation, used without support from specialized professionals, may be treated as operating in a critical situation, which moves it up the matrix.
Two practical aids come with this. CDSCO maintains a published list of classified medical device software; checking it is the first step for any new product, and a product already on the list has a settled class. Where a product is absent from the list, the manufacturer can apply through the CDSCO MD Online portal for a classification determination rather than guessing. Use that route for anything borderline, because a classification assumption that fails during review costs far more time than a determination request does before filing.
One structural point the final guidance makes explicit for diagnostics: IVD software runs on a parallel set of forms. Where a non-IVD MDSW with no predicate takes the investigational device route (clinical investigation permission granted in Form MD-23, then pre-commercialization permission via Form MD-26 granted as MD-27), a new IVD MDSW takes clinical performance evaluation permission via Form MD-24 (granted as MD-25) and its pre-commercialization permission via Form MD-28 (granted as MD-29). The surrounding scaffolding of test licences and manufacturing or import licences is shared. Teams filing diagnostic software should build their project plan on the IVD arm from the start.
The intended use statement: the sentence that decides everything
The guidance treats the intended use statement as the anchor of the entire application, and it lists the parameters an applicant should address when drafting one: the medical purpose; the disease or condition targeted and whether it is critical; the intended patient population; the intended users; the intended use environment; contraindications; the device software function; and the software platform it runs on. The guidance acknowledges that some parameters will not apply to every product, and that content such as contraindications can sit outside the statement itself.
The statement must make clear what kind of claim the software makes on clinical decision making. Decision support software that informs a clinician, software that drives a device, and software that delivers a definitive diagnosis or treatment recommendation are different products in the regulator's eyes, and they classify differently even if the underlying code is similar. The classification matrix reads directly off this statement, which means every word in it either raises or contains your regulatory burden. Draft it deliberately, keep it consistent across the application, the labeling, and the marketing material, and expect reviewers to compare those sources against each other.
The AI and machine learning layer
The most closely watched part of the guidance is its treatment of AI. The final document regulates AI enabled software through the same MDSW framework, with a set of additional expectations that apply across the product lifecycle.
Disclosure of methodology. Applicants are expected to describe the methodology underlying the software: whether it is rule based or uses AI or machine learning, whether neural networks are involved, whether the algorithm is fixed or adaptive, and what degree of autonomy the software has in the clinical workflow. A locked model that flags images for radiologist review and an adaptive model that issues treatment recommendations are at opposite ends of the disclosure and scrutiny spectrum.
Dataset transparency. Manufacturers are expected to disclose the composition of the datasets used for training, validation, and testing, including demographic distribution, geographic origin, and clinical diversity, and to state whether the data is real world data drawn from public databases or published literature or artificially generated synthetic data. This puts dataset documentation, which many development teams treat as internal engineering material, squarely into the regulatory file.
Performance in Indian populations. The guidance emphasizes that AI enabled MDSW must perform appropriately across the populations, healthcare settings, and operational environments relevant to its intended use in India. Where a model was trained or validated abroad, the manufacturer may need to justify its applicability to Indian clinical settings and supplement foreign evidence with validation in representative Indian populations. For global developers this is the provision to plan around: an FDA clearance or CE marking built on North American or European data will support an Indian application, and it may still leave a local validation gap to close.
Named AI risks. The guidance identifies the failure modes it expects manufacturers to assess and control: bias, lack of explainability, model drift, poor generalizability, and hallucination. Each of these should appear in the risk management file with an analysis and a control strategy, and each is expected to be monitored after launch, because the guidance frames post-market surveillance of AI products as continuous performance monitoring, explicitly including drift and bias.
The Algorithm Change Protocol (ACP). For models that will change after approval, the guidance provides for an ACP: an overview, prepared in advance, of the procedures that will govern modifications so that changes do not compromise the software's safety or intended use. The final text specifies its expected contents: a data management plan, a performance evaluation and monitoring plan with assessment metrics, a statistical analysis plan, assessment frequency and performance targets, an algorithm retraining plan, a software update plan covering version tracking, verification and validation, update triggers, and transparent communication of updates to users, and a rollback plan with triggers and backup and recovery procedures. The ACP may be submitted as part of the risk management file. It operates alongside the Sixth Schedule change rules: minor changes, such as bug fixes, security patches, version changes that do not affect intended use, safety, or effectiveness, and performance re-tuning within validated ranges, are notified to the licensing authority, while major changes, including modifications to software design or system requirements, a new clinical claim, a new data input type, or a version change that affects intended use, safety, effectiveness, or risk controls, require prior approval. Changes made under an approved ACP still flow through that notification or approval mechanism; what the ACP provides is a pre-agreed, bounded frame that keeps routine iteration on the notification side of the line instead of reopening scrutiny of the whole product. A defensible ACP requires the engineering team to define its release discipline in regulatory terms, so it belongs on the critical path of any adaptive AI submission.
Quality management system and standards
The guidance requires a QMS covering the organizational structure and the full software lifecycle: design, development, product planning, configuration, deployment, and maintenance, consistent with MDR 2017's Fifth Schedule requirements. The QMS must be documented, controlled, and proportionate to the risk class, with mechanisms for continuous performance assurance and compliance with applicable cybersecurity standards. Two concrete expectations stand out: the QMS documentation is expected to cover software architecture, requirements and design specifications, source code management, version control, and release management; and manufacturers should maintain and periodically update a Software Bill of Materials (SBOM) covering third party, open source, and commercial components, with processes for monitoring, assessing, and mitigating known vulnerabilities in those components across the lifecycle. Procedurally, domestic manufacturers submit an undertaking of compliance, while overseas manufacturers provide a notarized QMS certificate issued by their national regulatory authority or competent body.
On standards, the guidance sets a three-tier hierarchy: MDSW should conform to standards laid down by the Bureau of Indian Standards or notified by the Ministry of Health and Family Welfare; where none exist, to relevant ISO or IEC standards or other pharmacopoeial standards; and where even those are not specified, to the manufacturer's own validated standards. The guidance's illustrative list names the familiar core, IEC 62304 for the software lifecycle, ISO 14971 for risk management, ISO 13485 for the quality system, IEC 82304-1 for health software safety, IEC 81001-5-1 and ISO/IEC 27001 on the security side, and IEC 62366-1 for usability, and notably brings the AI governance set into scope: ISO/IEC 23894 on AI risk management, ISO/IEC 42001 on AI management systems, and ISO 24291 on machine learning in medical applications.
The guidance also speaks to the wider digital health ecosystem, naming interoperability, consent based data governance, secure information exchange, privacy and confidentiality, and digital traceability and accountability as regulatory quality expectations. It anchors these to Indian law and infrastructure: data collection and use are expected to comply with the Digital Personal Data Protection Act, 2023, and software handling patient health information should align with Ayushman Bharat Digital Mission building blocks such as ABHA, the Health Facility Registry, and the Healthcare Professional Registry, where applicable. Software companies used to treating privacy and interoperability as product features should note that CDSCO now frames them as license relevant qualities.
Documentation: what your file must demonstrate
The documentation expectations follow the lifecycle. The technical file for MDSW is expected to demonstrate the intended use, the software architecture and design, risk management, verification and validation, cybersecurity controls, clinical evaluation where applicable, and the software lifecycle processes under which the product is built and maintained.
For AI enabled MDSW, the file grows by the AI specific layer: algorithm design documentation, the training, validation, and testing datasets, evidence of performance across the relevant populations, bias assessment, explainability documentation, and the Algorithm Change Protocol where one is used.
The stated benchmark is that documentation must be detailed enough to demonstrate safety, performance, and regulatory compliance. Teams that already maintain IEC 62304 lifecycle records, a living ISO 14971 risk file, and rigorous dataset documentation will find the file assembles from what they have. Teams that document retrospectively will find the gap between engineering reality and regulatory record is the true scope of their submission project.
Post-market obligations
Approval is the midpoint of the compliance lifecycle, and the guidance is explicit about what follows it. Manufacturers must operate post-market surveillance appropriate to the product: monitoring the software's performance in real use, identifying and addressing defects, cybersecurity vulnerabilities, and safety issues, and maintaining records of updates and corrective actions. The PMS plan is submitted with the application, proportionate to the risk class, and the reporting obligations carry deadlines: suspected unexpected serious adverse events, and the action taken including any recall, must be reported to the licensing authority within fifteen days of coming to the licence holder's notice, and importers must report within fifteen days any administrative action taken against the product by a regulator in any country where it is marketed. Software approved through the no-predicate route is additionally subject to periodic safety update reports, and licence holders are expected to build the collection of real world evidence from Indian healthcare settings into their surveillance. For AI enabled products the surveillance expectation is continuous and names the AI specific risks again: performance change, bias, drift, and hallucination remain under active monitoring for as long as the product is on the market.
Practically, this means a named owner for post-market monitoring, defined performance metrics with thresholds that trigger investigation, a vulnerability handling process, and an update log that reconciles against the ACP where one exists. Reviewers can ask how each deployed version relates to the licensed one, and the update log is where that question gets answered.
What should manufacturers do now?
The guidance is operative, with licensing authorities and stakeholders advised to work from it in applications and review. A reasonable action sequence:
- Inventory your functions. List every function in your product portfolio that could carry a medical purpose under the definition above, remembering that the assessment is function by function, and that prediction counts.
- Check the classified MDSW list. If your product type appears, your class is settled. If it does not, and the classification is not obvious from the matrix, file for a classification determination through the MD Online portal before building your dossier.
- Rewrite intended use statements against the guidance's parameter list, and reconcile labeling and marketing claims with them.
- Gap-assess your file against the documentation expectations: lifecycle records, risk file, V&V, cybersecurity, and for AI products the dataset, bias, explainability, and India-applicability evidence.
- Draft the ACP early if your model will change after launch. It shapes the engineering release process, so it cannot be bolted on at filing time.
- Review in-flight applications. If you filed under draft-era assumptions, particularly SaMD/SiMD framing, check with your reviewer whether alignment to the final guidance is expected before the file progresses.
Frequently asked questions
Does the guidance create a new license type for software? No. MDSW is licensed through the existing MDR 2017 pathways. The guidance defines scope, classification, and documentation expectations within that system.
Is my wellness or fitness app regulated now? Software intended solely for general wellness, fitness, education, or training, with no medical purpose, remains outside regulation. The assessment is function specific: a single feature with a medical purpose, such as analyzing readings to flag a health condition, can bring that function into scope even when the rest of the app is exempt.
We hold FDA clearance and CE marking. Does India accept them? They help substantively, and they do not replace an Indian license. For AI products specifically, the guidance signals that evidence generated abroad may need supplementing with validation applicable to Indian populations and settings. Plan for that question rather than assuming reciprocity.
Our model retrains regularly. Do we need a new license each time? Under an accepted Algorithm Change Protocol, updates within the predefined, bounded modification rules do not require a fresh application for each iteration. Changes outside the protocol do. Without an ACP, treat significant algorithm changes as licensing events.
Who reviews our application? It follows your class: State Licensing Authority for Class A and B, the Central Licensing Authority for Class C and D. The classification matrix, and where needed a formal determination, tells you which door you are filing at.
Does the guidance apply to software already on the market? The guidance is a clarification of expectations under MDR 2017 rather than a new law, and authorities have been directed to apply it to submissions. Marketed products should be gap-assessed against it, particularly on post-market surveillance and documentation, ahead of renewals, changes, or inspections.
How EvySaif can help
EvySaif Research and Medical Affairs Solutions supports software and device companies through every stage of this framework: regulatory status and classification assessments, intended use drafting, technical documentation and dossier preparation, AI specific documentation including Algorithm Change Protocols, QMS alignment, and submission support before CDSCO and State Licensing Authorities, alongside parallel EU, US, and MENA strategies for the same product.
If you are working out where your software stands under the final guidance, or reconciling an in-flight application with it, write to info@evysaif.com or use the contact page. A classification and gap discussion typically takes a week and prevents the months that a misclassified or under-documented application loses in review.
This article is based on the final Guidance Document on Medical Device Software, Doc No. CDSCO/MD/GD/MDSW/01/2026, released by CDSCO circular on 21 July 2026, and reflects the position as of 12 August 2026. It is general information, and specific products require specific assessment; verify current requirements before acting.