Guida CDSCO software DM 2026: mappa MDR 2017

La Central Drugs Standard Control Organization (CDSCO) dell'India ha pubblicato il suo attuale Guidance Document on Medical Device Software il 21 luglio 2026. Il documento di 62 pagine, numerato CDSCO/MD/GD/MDSW/01/2026, raccoglie l'attuale approccio della CDSCO al software per dispositivi medici (MDSW), compreso il software per diagnosi in vitro (IVD), in un unico riferimento operativo ai sensi delle Medical Devices Rules, 2017 (MDR 2017).

Lo status è rilevante. La CDSCO afferma che la linea guida riflette le prassi attuali ai sensi delle MDR 2017 e “non debba essere intesa erroneamente come un nuovo controllo normativo.” Si tratta di una guida per la consapevolezza pubblica, non di una nuova regolamentazione né di un sostituto del Drugs and Cosmetics Act, delle MDR 2017 o delle successive chiarificazioni della CDSCO. Il cambiamento pratico non riguarda quindi una nuova legge sul software, bensì una mappa molto più chiara di come la CDSCO si aspetta che il quadro esistente venga applicato alle sottomissioni di software, al rilascio di licenze, ai sistemi di qualità, alle modifiche e ai controlli post-commercializzazione.

Leggi la pagina ufficiale degli avvisi sui dispositivi medici della CDSCO o apri il PDF completo della linea guida.

Quale software rientra nel campo di applicazione

La linea guida si applica quando il software, da solo o in combinazione con un altro prodotto, ha una destinazione d'uso medica e soddisfa la definizione di dispositivo medico ai sensi della legislazione indiana. La CDSCO utilizza MDSW come termine ombrello che include anche il software per dispositivi medico-diagnostici in vitro (IVD), a meno che il documento non specifichi diversamente.

La destinazione d'uso costituisce la linea di demarcazione. La CDSCO esclude il software utilizzato esclusivamente per il benessere generale, la promozione di uno stile di vita sano, il monitoraggio di routine dei parametri corporei o il fitness, a condizione che non sia destinato a uno scopo medico. Un'etichettatura orientata al benessere non neutralizza le rivendicazioni diagnostiche, di monitoraggio, predittive, terapeutiche o altre indicazioni mediche. I fabbricanti dovrebbero pertanto armonizzare la dichiarazione sulla destinazione d'uso tra prodotto, domanda di autorizzazione, etichettatura, istruzioni per l'uso e materiale promozionale prima di fare affidamento su tale esclusione.

Il documento non si applica solo alle applicazioni autonome. I suoi esempi e le sezioni relative alle domande di autorizzazione riguardano software che opera in modo indipendente, software che pilota o influenza l'hardware, sistemi connessi in cloud o in rete, funzionalità basate su IA/ML e software per IVD. È redatto per fabbricanti, importatori, innovatori, ricercatori e altri richiedenti che cercano approvazioni normative.

La classificazione parte sempre dalla destinazione d'uso

Il software MDSW segue le quattro classi di rischio già utilizzate dalle MDR 2017:

La CDSCO stabilisce che la classificazione del software si basa fondamentalmente sulla destinazione d'uso e sulle regole di classificazione contenute nel Primo Allegato delle MDR 2017. Qualora si applichi più di una regola, si applica la regola più severa che determina la classe superiore. La linea guida fornisce illustrazioni pratiche, che tuttavia non sostituiscono la razionale di classificazione specifica per il singolo prodotto.

Per un portafoglio software, l'unità di analisi utile non è quindi la codebase o la piattaforma commerciale, bensì ciascuna destinazione d'uso regolamentata e il danno che potrebbe derivare dalle informazioni o dal controllo forniti dalla funzione. Due moduli che condividono la stessa architettura tecnica possono richiedere un trattamento normativo diverso se le rispettive destinazioni d'uso mediche e i relativi rischi differiscono.

Il percorso di sottomissione e l'autorità competente per il rilascio delle licenze

La linea guida suddivide il percorso online in base alla tipologia di domanda:

• Licenze di prova: sottomissione tramite il National Single Window System dell'India.
• Altre autorizzazioni normative, licenze di produzione o importazione e registrazione per la vendita e la distribuzione: sottomissione tramite l'Online System for Medical Devices.

La responsabilità del rilascio delle licenze varia inoltre in base all'operazione e alla classe di rischio. La Tabella 5 della CDSCO assegna le licenze di prova e le licenze di importazione alla Central Licensing Authority (CLA) per tutte le classi. Le licenze di produzione per i software MDSW di Classe A e B fanno capo alla State Licensing Authority (SLA), mentre le licenze di produzione di Classe C e D competono alla CLA. I dispositivi di Classe A non sterili e privi di funzione di misura sono esenti da licenza e richiedono la registrazione ai sensi del Capitolo IIIB delle MDR 2017; tale esenzione non deve essere generalizzata ad altre configurazioni software di Classe A senza verificare le condizioni applicabili.

Questa suddivisione è operativamente importante per le aziende che dispongono sia di produzione indiana sia di prodotti importati. La “sottomissione alla CDSCO” non costituisce un unico percorso indifferenziato: il portale, il modulo, l'autorità e il dossier corretti dipendono da ciò per cui il richiedente richiede l'autorizzazione.

Che cosa mappa ora il dossier in un unico luogo

Le Sezioni 12.1–12.5 e l'Allegato A organizzano gli elementi di prova richiesti tra licenze di prova, indagini cliniche o valutazioni delle prestazioni per IVD, autorizzazioni per dispositivi d'indagine, licenze commerciali di produzione/importazione e obblighi post-commercializzazione. L'applicabilità dipende comunque dal prodotto e dalla domanda, ma la linea guida rende visibili i principali ambiti di prova:

• destinazione d'uso, indicazioni, utilizzatori previsti, ambiente d'uso, input, output, controindicazioni e limitazioni;
• descrizione del dispositivo, architettura software, gestione delle versioni, interfacce, dipendenze e relazione tra software ed eventuale hardware;
• razionale di classificazione e, ove applicabile, confronto con il dispositivo predicato;
• ciclo di vita dello sviluppo software, requisiti, progettazione, verifica, convalida, configurazione, gestione dei difetti e delle modifiche;
• gestione del rischio relativa a rischi clinici, di usabilità, dei dati, di sicurezza informatica, interoperabilità e legati all'IA, ove applicabile;
• prove cliniche o di prestazione adeguate al software e al percorso normativo;
• etichettatura, informazioni elettroniche, installazione, manutenzione, aggiornamento e tracciabilità delle versioni;
• prove QMS per i siti di produzione nazionali o esteri; e
• sorveglianza post-commercializzazione, vigilanza, azioni correttive, richiamo ed azioni sul campo specifiche per il software.

L'Allegato A trasforma tali ambiti in checklist per le domande. Specifica inoltre che, qualora un documento elencato non sia applicabile, il richiedente deve fornire una giustificazione dettagliata anziché ometterlo silenziosamente.

QMS, norme tecniche, cybersecurity e modifiche al software

La CDSCO colloca i controlli sul ciclo di vita del software all'interno del sistema di gestione della qualità. I fabbricanti nazionali devono stabilire e mantenere procedure e registrazioni QMS e presentare la dichiarazione di conformità al Quinto Allegato delle MDR 2017 unitamente alla domanda di licenza di produzione. Per le importazioni, il fabbricante estero deve corredare la domanda di licenza di importazione con le prove relative al QMS descritte nella linea guida.

La sezione sulle norme tecniche mantiene la gerarchia delle MDR 2017: prima le norme BIS applicabili o le norme indiane notificate, quindi le norme ISO, IEC o altre norme internazionali indicate qualora non sia disponibile una norma indiana, e infine le norme validate del fabbricante quando non è specificata alcuna delle precedenti. La relativa tabella illustrativa sul MDSW include ISO 13485, ISO 14971, IEC 62304, IEC 82304-1 e IEC 81001-5-1, tra gli altri. La tabella precisa che le norme “possono essere applicabili”; non si tratta di una dichiarazione che ogni norma elencata si applichi in modo identico a ciascun prodotto.

Per quanto riguarda la sicurezza del ciclo di vita, la CDSCO dichiara che i fabbricanti dovrebbero mantenere e aggiornare periodicamente una distinta base, inclusa una software bill of materials (SBOM), che copra secondo opportuno i componenti di terze parti, open source e commerciali. La linea guida collega l'SBOM al monitoraggio, alla valutazione e alla mitigazione delle vulnerabilità note. Richiede inoltre un monitoraggio documentato delle prestazioni post-distribuzione, compresi il degrado clinicamente significativo, l'algorithm drift, le vulnerabilità di cybersecurity e i risultati non intesi.

La formulazione relativa alla pianificazione delle modifiche dell'IA richiede attenzione. La linea guida indica che un Algorithm Change Protocol (ACP) può essere predisposto, ove applicabile, in base alla natura e ai rischi del MDSW. Un ACP non viene quindi presentato come un artefatto obbligatorio per qualsiasi dispositivo software. Ove utilizzato, deve descrivere le procedure volte a garantire che le modifiche non compromettano la sicurezza o la destinazione d'uso, compresi i dati pertinenti, la convalida, il rischio, il monitoraggio e i controlli di ripristino.

Gli obblighi post-commercializzazione dipendono dal rischio e dal percorso seguito

L'approvazione commerciale non conclude il ciclo di vita del software. La linea guida collega le condizioni di licenza, la segnalazione di eventi avversi, le azioni correttive di sicurezza sul campo, i richiami, gli aggiornamenti e la tracciabilità delle versioni al quadro post-commercializzazione esistente delle MDR 2017. Per il software, un richiamo può comprendere l'interruzione della distribuzione, la disinstallazione o la dismissione del prodotto da canali, reti o hardware.

La disposizione relativa al Periodic Safety Update Report (PSUR) è più circoscritta rispetto a una norma generale valida per tutti i MDSW. La CDSCO specifica che i MDSW approvati per la commercializzazione a seguito di indagini cliniche — come un dispositivo privo di predicato — devono essere attentamente monitorati e che il fabbricante o l'importatore deve fornire i PSUR secondo le condizioni stabilite dalle MDR 2017. I team dovrebbero mappare l'esatto obbligo post-commercializzazione in relazione al percorso di approvazione e alle condizioni di licenza, anziché copiare una tempistica universale da un altro prodotto.

Cosa dovrebbero fare ora i fabbricanti e gli importatori

La posizione di Pure Global è che la risposta più utile sia una valutazione controllata dei gap, non una riprogettazione radicale basata sulla parola “linea guida”.

1. Sostituire la bozza nel file di regulatory intelligence. Registrare il numero di documento del 21 luglio 2026 e archiviare la linea guida pubblicata come riferimento corrente.
2. Riconciliare la destinazione d'uso e la classificazione. Confermare che le rivendicazioni del prodotto, i confini dei moduli, le regole di classificazione e l'analisi della regola applicabile più severa concordino.
3. Confermare il percorso specifico per la transazione. Separare le attività di prova, produzione, importazione, indagine clinica e registrazione commerciale, e mappare ciascuna al portale, modulo e autorità competente per il rilascio delle licenze corretti.
4. Raccordare il dossier alle Sezioni 12 e all'Allegato A. Identificare le evidenze mancanti e documentare il motivo per cui una voce della lista di controllo non è applicabile.
5. Testare il QMS rispetto alla realtà del software. Confermare che le registrazioni relative al ciclo di vita, al rischio, alla configurazione, a verifica/validazione, alle vulnerabilità, alla SBOM, al monitoraggio e alle modifiche esistano come evidenze controllate anziché come artefatti ingegneristici esterni al QMS.
6. Definire il confine di modifica prima del prossimo rilascio. Determinare quali modifiche richiedano validazione, documentazione e valutazione regolatoria, e se un ACP sia utile per la specifica funzione di IA/ML.
7. Allineare i dati post-commercializzazione con le versioni. Reclami, eventi avversi, deriva delle prestazioni, vulnerabilità, azioni correttive e richiami devono rimanere tracciabili rispetto alla versione del software effettivamente distribuita.

Per il percorso di registrazione indiano più ampio, consultare la guida all'accesso al mercato dei dispositivi medici in India di Pure Global. Per una visione trasversale a più mercati su come il software basato sull'IA viene classificato e mantenuto, consultare IA come dispositivo medico: la mappa globale di regolamentazione, registrazione e accesso al mercato.

La conclusione principale è precisa: la CDSCO non ha annunciato un nuovo regime autonomo per il software. Ha fornito il quadro consolidato più chiaro mai pubblicato finora su come il software per dispositivi medici si inserisca all'interno dell'esistente sistema MDR 2017 dell'India. Il valore in termini di conformità deriva dall'uso di tale mappa per evidenziare le incongruenze prima che si manifestino in una domanda di licenza, nel rilascio di un software o in un evento post-commercializzazione.