Guide CDSCO 2026 : logiciels DM et MDR 2017

La Central Drugs Standard Control Organization (CDSCO) d'Inde a publié son Document d'orientation sur les logiciels de dispositifs médicaux actuel le 21 juillet 2026. Ce document de 62 pages, numéroté CDSCO/MD/GD/MDSW/01/2026, rassemble l'approche actuelle de la CDSCO concernant les logiciels de dispositifs médicaux (MDSW), y compris les logiciels de diagnostic in vitro (DIV), au sein d'une référence opérationnelle unique sous les Medical Devices Rules, 2017 (MDR 2017).

Le statut du document a son importance. La CDSCO précise que le document d'orientation reflète les pratiques actuelles dans le cadre des MDR 2017 et « ne doit pas être interprété à tort comme un nouveau contrôle réglementaire. » Il s'agit d'une orientation destinée à l'information du public, et non d'une nouvelle réglementation ni d'un substitut au Drugs and Cosmetics Act, aux MDR 2017 ou aux clarifications ultérieures de la CDSCO. Le changement pratique n'est donc pas une nouvelle loi sur les logiciels ; c'est une cartographie nettement plus claire de la manière dont la CDSCO s'attend à ce que le cadre existant soit appliqué aux demandes relatives aux logiciels, à la délivrance des licences, aux systèmes qualité, aux modifications et aux contrôles post-commercialisation.

Consulter la page officielle des avis relatifs aux dispositifs médicaux de la CDSCO ou ouvrir le PDF complet du document d'orientation.

Quels logiciels sont concernés

Le document d'orientation s'applique lorsqu'un logiciel, seul ou en combinaison avec un autre produit, a une destination médicale et répond à la définition d'un dispositif médical selon le droit indien. La CDSCO utilise MDSW comme un terme générique qui englobe également les logiciels de dispositifs médicaux DIV, sauf indication contraire dans le document.

La destination est la ligne de démarcation. La CDSCO exclut les logiciels utilisés uniquement pour le bien-être général, la promotion d'un mode de vie sain, le suivi de routine des paramètres corporels ou la forme physique, à condition qu'ils ne soient pas destinés à une fin médicale. Une étiquette de bien-être ne neutralise pas les revendications de diagnostic, de surveillance, de prédiction, de traitement ou d'autres revendications médicales. Les fabricants doivent donc harmoniser la déclaration de destination entre le produit, le dossier de demande, l'étiquetage, la notice d'utilisation et le matériel promotionnel avant de s'appuyer sur cette exclusion.

Le document ne concerne pas seulement les applications autonomes. Ses exemples et ses sections relatives aux dossiers traitent des logiciels qui fonctionnent de manière indépendante, des logiciels qui pilotent ou influent sur le matériel, des systèmes connectés au cloud ou au réseau, des fonctions d'IA/apprentissage automatique, et des logiciels DIV. Il est rédigé à l'intention des fabricants, importateurs, innovateurs, chercheurs et autres demandeurs sollicitant des autorisations réglementaires.

La classification repose toujours d'abord sur la destination

Les MDSW suivent les quatre classes de risque déjà utilisées par les MDR 2017 :

La CDSCO précise que la classification des logiciels repose fondamentalement sur la destination et sur les règles de classification énoncées dans la première annexe (First Schedule) des MDR 2017. Lorsque plusieurs règles s'appliquent, la règle la plus stricte conduisant à la classe la plus élevée s'applique. Le document d'orientation fournit des illustrations pratiques, mais celles-ci ne remplacent pas une justification de classification propre à un produit spécifique.

Pour un portefeuille de logiciels, l'unité d'analyse pertinente n'est donc pas la base de code ni la plateforme commerciale. Il s'agit de chaque destination réglementée et du préjudice qui pourrait découler des informations ou du contrôle fournis par la fonction. Deux modules partageant la même architecture technique peuvent nécessiter un traitement réglementaire différent si leurs destinations médicales et leurs risques diffèrent.

La voie de dépôt et l'autorité de délivrance des licences

Le document d'orientation distingue la voie en ligne selon le type de demande :

• Licences de test : soumettre via le National Single Window System de l'Inde.
• Autres autorisations réglementaires, licences de fabrication ou d'importation et enregistrement pour la vente et la distribution : soumettre via l'Online System for Medical Devices.

La responsabilité en matière de licences varie également selon la transaction et la classe de risque. Le tableau 5 de la CDSCO attribue les licences de test et les licences d'importation à l'Autorité centrale de délivrance des licences (CLA) pour toutes les classes. Les licences de fabrication pour les MDSW de classes A et B relèvent de l'Autorité d'État de délivrance des licences (SLA), tandis que les licences de fabrication de classes C et D relèvent de la CLA. Les dispositifs de classe A non stériles et sans fonction de mesurage sont exemptés de licence et nécessitent un enregistrement au titre du chapitre IIIB des MDR 2017 ; cette exemption ne doit pas être généralisée à d'autres configurations de logiciels de classe A sans vérifier les conditions applicables.

Cette division est opérationnellement importante pour les entreprises qui réalisent à la fois de la fabrication en Inde et de l'importation de produits. Le « dépôt CDSCO » n'est pas une voie unique indifférenciée : le portail, le formulaire, l'autorité et le dossier appropriés dépendent de ce pour quoi le demandeur sollicite une autorisation.

Ce que le dossier cartographie désormais en un seul endroit

Les sections 12.1–12.5 et l'Annexe A organisent les preuves attendues pour les licences de test, les investigations cliniques ou évaluations des performances des DIV, les autorisations de dispositifs d'investigation, les licences commerciales de fabrication/importation et les obligations post-commercialisation. L'applicabilité dépend toujours du produit et de la demande, mais le document d'orientation rend visibles les principaux domaines de preuves :

• destination, indications, utilisateurs cibles, environnement d'utilisation, données d'entrée, données de sortie, contre-indications et limites ;
• description du dispositif, architecture logicielle, gestion des versions, interfaces, dépendances et relation entre le logiciel et tout matériel ;
• justification de la classification et, le cas échéant, comparaison avec un dispositif prédicat ;
• cycle de vie du développement logiciel, exigences, conception, vérification, validation, configuration, enregistrements relatifs aux défauts et à la gestion des modifications ;
• gestion des risques couvrant les risques cliniques, d'aptitude à l'utilisation, de données, de cybersécurité, d'interopérabilité et liés à l'IA, le cas échéant ;
• preuves cliniques ou de performances appropriées au logiciel et à la voie réglementaire ;
• étiquetage, informations électroniques, installation, maintenance, mise à jour et informations de traçabilité des versions ;
• preuves relatives au SMQ pour les sites de fabrication nationaux ou étrangers ; et
• surveillance après commercialisation, vigilance, actions correctives, rappels et actions de sécurité sur le terrain spécifiques aux logiciels.

L'Annexe A transforme ces domaines en listes de contrôle pour les demandes. Elle indique également que lorsqu'un document répertorié n'est pas applicable, le demandeur doit fournir une justification détaillée plutôt que de l'omettre silencieusement.

SMQ, normes, cybersécurité et modifications des logiciels

La CDSCO intègre les contrôles du cycle de vie des logiciels au sein du système de management de la qualité. Les fabricants nationaux doivent établir et maintenir des procédures et des enregistrements de SMQ et soumettre l'engagement de conformité à la cinquième annexe (Fifth Schedule) des MDR 2017 lors d'une demande de licence de fabrication. Pour les importations, le fabricant étranger doit étayer la demande de licence d'importation avec les preuves de SMQ décrites dans le document d'orientation.

La section relative aux normes conserve la hiérarchie des MDR 2017 : les normes BIS applicables ou normes indiennes notifiées en premier lieu, puis les normes ISO, IEC ou autres normes internationales énoncées lorsqu'aucune norme indienne n'est disponible, et les normes validées du fabricant lorsqu'aucune de ces normes n'est spécifiée. Son tableau illustratif relatif aux MDSW inclut notamment ISO 13485, ISO 14971, IEC 62304, IEC 82304-1 et IEC 81001-5-1. Le tableau indique que les normes « peuvent être applicables » ; il ne s'agit pas d'une déclaration selon laquelle chaque norme répertoriée s'applique de manière identique à chaque produit.

Pour la sécurité du cycle de vie, la CDSCO indique que les fabricants doivent maintenir et mettre à jour périodiquement une liste des composants, y compris une liste des composants logiciels (SBOM), couvrant les composants tiers, open-source et commerciaux, le cas échéant. Le document d'orientation associe le SBOM à la surveillance, à l'évaluation et à l'atténuation des vulnérabilités connues. Il exige également un suivi documenté des performances après déploiement, y compris la dégradation cliniquement significative, la dérive des algorithmes, les vulnérabilités de cybersécurité et les résultats imprévus.

La formulation concernant la planification des modifications relatives à l'IA exige de la prudence. Le document d'orientation indique qu'un protocole de modification d'algorithme (ACP) peut être élaboré, le cas échéant, en fonction de la nature et des risques du MDSW. Un ACP n'est donc pas présenté comme un document obligatoire pour tout dispositif logiciel. Lorsqu'il est utilisé, il doit décrire les procédures visant à garantir que les modifications ne compromettent pas la sécurité ni la destination, y compris les données pertinentes, la validation, les risques, la surveillance et les contrôles de retour en arrière.

Les obligations post-commercialisation dépendent du risque et de la voie réglementaire

L'homologation commerciale ne met pas fin au cycle de vie du logiciel. Le document d'orientation associe les conditions de licence, la déclaration des événements indésirables, les actions correctives de sécurité sur le terrain, les rappels, les mises à jour et la traçabilité des versions au cadre post-commercialisation existant des MDR 2017. Pour les logiciels, un rappel peut inclure l'arrêt de la distribution, la désinstallation ou le déclassement du produit des canaux, réseaux ou matériels.

La déclaration concernant le rapport périodique actualisé de sécurité (PSUR) est plus restreinte qu'une règle générale s'appliquant à tous les MDSW. La CDSCO indique spécifiquement que les MDSW dont la commercialisation a été approuvée après des investigations cliniques — comme un dispositif sans prédicat — doivent faire l'objet d'une surveillance étroite et que le fabricant ou l'importateur doit fournir des PSUR selon les conditions énoncées dans les MDR 2017. Les équipes doivent associer l'obligation post-commercialisation exacte à la voie d'homologation et aux conditions de licence plutôt que de copier un rythme universel à partir d'un autre produit.

Ce que les fabricants et les importateurs doivent faire dès à présent

L'avis de Pure Global est que la réponse la plus utile est une analyse d'écart contrôlée, et non une refonte globale basée sur le mot « guidance ».

1. Remplacer le projet dans le dossier de veille réglementaire. Consigner le numéro de document du 21 juillet 2026 et archiver la ligne directrice publiée comme référence actuelle.
2. Rapprocher la destination et la classification. Confirmer que les revendications du produit, les limites des modules, les règles de classification et l'analyse de la règle applicable la plus élevée concordent.
3. Confirmer la voie spécifique à la transaction. Séparer les activités d'essai, de fabrication, d'importation, d'investigation et d'enregistrement commercial, et associer chacune au portail, au formulaire et à l'autorité délivrant les licences appropriés.
4. Mettre en correspondance le dossier avec les sections 12 et l'annexe A. Identifier les preuves manquantes et documenter les raisons pour lesquelles un élément de la liste de contrôle n'est pas applicable.
5. Tester le SMQ à l'épreuve de la réalité du logiciel. Confirmer que les enregistrements relatifs au cycle de vie, aux risques, à la configuration, à la vérification/validation, aux vulnérabilités, au SBOM, à la surveillance et aux modifications existent sous forme de preuves maîtrisées plutôt que d'artefacts d'ingénierie extérieurs au SMQ.
6. Définir le périmètre de modification avant la prochaine version. Déterminer quelles modifications nécessitent une validation, une documentation et une évaluation réglementaire, et si un ACP est utile pour la fonction d'IA/ML spécifique.
7. Aligner les données post-commercialisation sur les versions. Les réclamations, événements indésirables, dérives de performances, vulnérabilités, corrections et rappels doivent rester traçables jusqu'à la version du logiciel effectivement déployée.

Pour le parcours d'enregistrement indien plus large, consultez le guide d'accès au marché des dispositifs médicaux en Inde de Pure Global. Pour une vision transversale de la manière dont les logiciels intégrant l'IA sont classés et maintenus, consultez L'IA en tant que dispositif médical : cartographie mondiale de la réglementation, de l'enregistrement et de l'accès au marché.

Le constat central est précis : la CDSCO n'a pas annoncé de nouveau régime distinct pour les logiciels. Elle a publié la synthèse consolidée la plus claire à ce jour sur la manière dont les logiciels de dispositifs médicaux s'intègrent dans le système MDR 2017 existant en Inde. La valeur en matière de conformité réside dans l'utilisation de cette cartographie pour révéler les incohérences avant qu'elles n'apparaissent dans une demande de licence, une version logicielle ou un événement post-commercialisation.