Indonésie KMK 951/2026 : AMM des dispositifs médicaux logiciels

Le ministre de la Santé d'Indonésie a publié le décret n° HK.01.07/MENKES/951/2026 relatif aux lignes directrices pour l'autorisation de mise sur le marché des dispositifs médicaux à base de logiciels (Kepmenkes/KMK 951/2026). Le décret a été signé le 7 septembre 2026 et est entré en vigueur le jour même. Il adopte le guide figurant dans son annexe comme référence (acuan) pour le gouvernement, les entreprises du secteur des dispositifs médicaux et les autres parties prenantes intervenant dans l'autorisation de mise sur le marché (izin edar) des dispositifs à base de logiciels. Le guide se présente comme une explication technique des exigences et des procédures d'autorisation de mise sur le marché. Lorsque cet article emploie le terme « doit », le guide lui-même utilise des formulations contraignantes (wajib ou harus) ou fait figurer l'élément parmi les obligations (kewajiban) du titulaire. Le décret ne contient aucune disposition transitoire pour les produits déjà enregistrés ou faisant l'objet d'une demande en cours d'examen.

Champ d'application

Le guide couvre trois groupes de produits :

• Logiciel en tant que dispositif médical (SaMD) : logiciel autonome ayant une finalité médicale qui ne fait pas partie intégrante d'un dispositif médical matériel. Cela inclut les logiciels destinés aux dispositifs de diagnostic in vitro (IVD), ainsi que les logiciels fonctionnant sur des plateformes d'usage général telles que des ordinateurs, des tablettes et des smartphones. Un logiciel qui ne fait que piloter ou contrôler un autre dispositif médical n'est pas un SaMD. Les exemples cités par le guide sont une application de surveillance du glucose, un algorithme prédisant le risque de crise cardiaque à partir de données d'ECG numériques, un logiciel de visualisation de radiographies sur une station de travail standard et une application de télésurveillance des signes vitaux.
• Logiciel intégré à un dispositif médical (SiMD) : logiciel embarqué dans un dispositif qui contribue à son fonctionnement. Ses fonctions comprennent, sans s'y limiter, l'actionnement ou le contrôle du dispositif, la modification de son état ou la production de résultats liés à sa fonction matérielle. Selon l'arbre de décision de classification du guide, le SiMD est enregistré en tant qu'accessoire du dispositif principal, et ses exigences ainsi que sa classe de risque suivent celles de ce dispositif. Les exemples donnés par le guide sont le traitement du signal dans les scanners IRM ou CT, l'automatisation des ventilateurs, les logiciels d'imagerie échographique et les logiciels de stimulation ou de défibrillation dans les stimulateurs cardiaques et les défibrillateurs implantables (ICD).
• Dispositifs médicaux comportant des applications d'intelligence artificielle : l'IA, y compris l'apprentissage automatique, le traitement automatique du langage naturel et les grands modèles de langage (LLM), n'est un dispositif médical que lorsqu'elle a une finalité médicale. Les résultats de l'IA générative tels que les images, le texte, l'audio ou la vidéo entrent dans le champ d'application lorsqu'ils sont destinés au diagnostic, à la surveillance, aux décisions thérapeutiques ou aux soins des patients. L'IA utilisée uniquement pour la gestion administrative des données, le stockage ou d'autres fonctions opérationnelles qui n'affectent pas le fonctionnement d'un dispositif est exclue.

Ce même arbre de décision considère qu'un logiciel n'est pas un dispositif médical lorsqu'il se limite à stocker, archiver, communiquer, effectuer des recherches simples ou appliquer une compression sans perte, ou lorsqu'il n'agit pas sur des données propres à un patient individuel. Un logiciel agissant sur des données propres à un patient n'est pas non plus un dispositif médical selon l'arbre de décision s'il n'exécute aucune des fonctions énumérées : l'acquisition, le traitement ou l'analyse de signaux ou de données de diagnostic in vitro (IVD), d'IRM, de NGS, de CGM ou de détection/diagnostic assistés par ordinateur ; l'affichage, l'analyse ou l'impression de signaux continus, d'images médicales ou de tracés d'ECG ; ou la fourniture de scores de risque de maladie, de probabilités ou de résultats critiques sur le plan temporel.

Fabrication, distribution et système qualité

La production est effectuée par un fabricant de dispositifs médicaux, qui doit être titulaire d'une licence commerciale indonésienne au titre du code KBLI pertinent et satisfaire aux bonnes pratiques de fabrication des dispositifs médicaux (CPB). La distribution est assurée par un distributeur de dispositifs médicaux ou sa succursale, qui doit être titulaire d'une licence commerciale et respecter les bonnes pratiques de distribution (CDB). Les fabricants comme les distributeurs doivent appliquer un système de gestion de la qualité. Le guide décrit un système de gestion de la qualité efficace comme comprenant la maîtrise des processus sous-traités, y compris les logiciels commerciaux prêts à l'emploi (COTS), le propriétaire du produit demeurant responsable de la sécurité et des performances.

Pour la mise en œuvre du système de gestion de la qualité, le guide énumère des normes pouvant servir de références, sans indication d'édition. Elles comprennent ISO 13485, ISO 14971, IEC 60601-1 et IEC 61010-1 (que le décret qualifie de normes ISO), IEC 62366-1, IEC 62304, IEC 82304, IEC 63450, IEC 63521 et ISO 27001.

Documents d'enregistrement

Vérification et validation du logiciel. Ces documents doivent respecter le cycle de vie de développement logiciel selon l'IEC 62304 ou une norme équivalente reconnue. Ils doivent au minimum couvrir la version du logiciel, la traçabilité, la maîtrise des modifications, l'interopérabilité et la cybersécurité. Si la version testée diffère de la version soumise, le demandeur doit fournir une comparaison des versions accompagnée d'une justification. Une validation supplémentaire est requise en présence de modifications importantes susceptibles d'affecter la sécurité, les performances ou l'utilisation prévue. La version commercialisée du logiciel doit figurer sur l'étiquette du dispositif et/ou sur l'interface logicielle.

Logiciels connectés. Les logiciels connectés à d'autres dispositifs, à des systèmes externes, à des réseaux ou à Internet requièrent des informations complémentaires dans le dossier. Celui-ci doit décrire les mécanismes d'échange de données qui protègent la confidentialité, l'intégrité et la disponibilité, ainsi que l'identification des vulnérabilités, l'analyse des risques, leur atténuation et les preuves de l'efficacité des mesures de contrôle.

Gestion des risques. La gestion des risques doit s'étendre à l'ensemble du cycle de vie du logiciel, en référence à des normes telles que ISO 14971. Chaque modification du logiciel doit faire l'objet d'une évaluation au titre des risques supplémentaires.

Dispositifs d'IA et d'apprentissage automatique. La conception, le développement, la validation, le déploiement ainsi que tout entraînement ou réentraînement des modèles d'IA doivent se dérouler dans le cadre du système de gestion de la qualité. Le tableau 3.1 du guide détaille ce que doit contenir un dossier AI/ML :

Les dispositifs faisant appel à l'apprentissage automatique continu doivent également documenter la manière dont les modifications apportées aux modèles sont maîtrisées afin de ne pas affecter la sécurité, les performances ou l'utilisation prévue. Cette documentation couvre la fréquence des mises à jour, la détection et l'atténuation des anomalies, le traitement des données en vie réelle, l'intégrité des jeux de données, la gestion des versions avec possibilité de retour à un algorithme antérieur, la traçabilité entre les données, l'entraînement et les résultats, ainsi qu'une stratégie de validation continue. Les dispositifs utilisant des modèles génératifs ou des LLM doivent également décrire le contrôle des résultats produits, l'atténuation des hallucinations, les limites d'utilisation, ainsi que la manière dont la cohérence et l'exactitude des informations médicales générées sont évaluées au cours de l'adaptation continue.

Preuves cliniques

Les preuves cliniques peuvent comprendre l'un quelconque des éléments suivants :

• une revue de la littérature et les recommandations de pratique clinique pertinentes ;
• une comparaison avec un logiciel similaire déjà commercialisé, le cas échéant ;
• les résultats d'essais cliniques, en particulier pour étayer de nouvelles allégations ou des modifications importantes de la fonction clinique.

Les essais cliniques pré-commercialisation dépendent du risque présenté par le dispositif et de l'importance de ses informations pour les décisions cliniques. Le guide classe les preuves cliniques comme bien établies ou novatrices, et cette catégorie sert de base pour décider si des preuves supplémentaires sont nécessaires. Les preuves devraient être choisies de manière proportionnée et sans imposer de charge excessive. Pour les logiciels à haut risque, l'évaluation clinique peut nécessiter un examen indépendant. La validation analytique et la validation clinique sont obligatoires pour tous les dispositifs à base de logiciels. La validation clinique a lieu tant avant qu'après la mise sur le marché. Une nouvelle utilisation prévue ou une nouvelle population cible exige de répéter l'évaluation clinique.

Le guide présente le tableau 3.2 sous forme de preuves cliniques recommandées, bien que le titre propre du tableau les qualifie de preuves cliniques « requises » pour l'autorisation de mise sur le marché. Il est structuré selon la gravité de la situation de soins et l'importance des informations fournies par le logiciel pour la décision de soins :

La gravité de la situation ne modifie pas les preuves énumérées ; seule l'importance des informations le fait.

Validation clinique locale pour certains logiciels importés

Certains dispositifs à base de logiciel importés nécessitent une validation clinique locale en Indonésie. Son objectif est de démontrer que le logiciel produit des résultats cliniquement significatifs pour la population cible indonésienne. Elle s'applique aux logiciels importés qui :

• ont fait l'objet d'un développement complémentaire et/ou d'un réentraînement à l'aide de données représentatives de la population indonésienne ; et/ou
• utilisent une IA présentant un niveau de risque modéré à élevé, en particulier pour le diagnostic, le dépistage ou la prise de décision clinique.

La validation peut se dérouler dans :

• des hôpitaux, des universités ou des laboratoires accrédités ;
• des unités techniques du ministère de la Santé responsables de la sécurité des équipements et des installations de santé, ou des services de génomique biomédicale et de santé.

L'unité biomédicale et de génomique peut apporter un accompagnement aux autres sites si nécessaire. La validation peut se dérouler en parallèle de la demande d'autorisation de mise sur le marché si les preuves cliniques et de performance du fabricant sont jointes. Les résultats doivent être soumis au plus tard un an après la délivrance de l'autorisation de mise sur le marché. Pendant la validation, le produit peut être utilisé de manière limitée à des fins d'évaluation ou dans le cadre d'aménagements spécifiques, à condition que la sécurité des patients ne soit pas compromise. Si les résultats diffèrent de manière significative des preuves cliniques initiales, des mesures administratives peuvent s'ensuivre en vertu de la réglementation applicable. Le guide précise que la validation locale devrait être efficace, proportionnée et fondée sur les risques, et qu'elle ne devrait pas entraver l'accès à l'innovation.

Bac à sable réglementaire et maturité technologique

Pour les logiciels ne disposant pas de preuves cliniques adéquates d'exactitude, de précision d'interprétation, de sécurité ou de performance au sein de la population indonésienne, l'entreprise peut mener son propre essai clinique conformément aux lignes directrices relatives aux essais cliniques de dispositifs médicaux. Elle peut également réaliser des essais limités par le biais d'un bac à sable réglementaire conformément à la réglementation applicable. Cette même section précise que les produits d'innovation en santé numérique faisant l'objet d'une demande d'autorisation de mise sur le marché en tant que dispositifs médicaux doivent avoir atteint le niveau de maturité technologique (TKT) 9. Le TKT 9 signifie qu'il a été prouvé que le système fonctionne avec succès dans son environnement d'exploitation réel, conformément à son utilisation prévue. Le guide ne définit pas la notion de « produit d'innovation en santé numérique » et n'indique pas si cette exigence s'applique au-delà des produits du bac à sable.

Étiquetage

L'étiquetage peut prendre la forme d'une étiquette, d'une notice d'utilisation, d'un manuel d'utilisation ou d'autres informations pertinentes. Il doit au minimum mentionner le nom du produit, le numéro de version du logiciel et le propriétaire du produit. Il doit également énoncer clairement l'utilisation prévue, les instructions, les informations de performance et les informations de sécurité, y compris les avertissements. Les logiciels fournis sur support physique (CD, DVD ou clé USB) nécessitent une étiquette physique et une notice d'utilisation, sur support imprimé ou sous la forme d'un lien. Les logiciels téléchargés ou basés sur le Web doivent être enregistrés avec des captures d'écran de l'interface, telles qu'un écran de démarrage ou une brochure, faisant apparaître les éléments d'identification et le numéro de version. Les utilisateurs doivent également recevoir le lien de téléchargement, la procédure de téléchargement, le guide d'installation et la procédure d'utilisation.

Modifications après approbation

Le guide divise les modifications apportées à un dispositif à base de logiciel approuvé en deux catégories, complétées par une règle subsidiaire :

Chaque modification doit être documentée dans le système de gestion de la qualité.

Obligations du titulaire de l'autorisation de mise sur le marché

Le titulaire doit respecter des principes éthiques applicables aux dispositifs à base de logiciel :

• inclusivité et non-discrimination ;
• sécurité et sûreté ;
• humanité ;
• accessibilité ;
• transparence ;
• crédibilité et responsabilité ;
• protection des données personnelles ;
• durabilité ;
• propriété intellectuelle.

Les incidents relatifs à la protection des données doivent être signalés conformément à la réglementation applicable. Pour les dispositifs d'IA/ML, les bonnes pratiques d'apprentissage automatique (GMLP) sont obligatoires selon dix principes. Ceux-ci vont de l'utilisation prévue et de l'expertise multidisciplinaire jusqu'à la surveillance après commercialisation et la gestion des modifications, y compris les risques liés aux mises à jour et au réentraînement. Pour les logiciels d'IA/ML, la gestion des données doit respecter des principes comprenant :

• la sécurité et la confidentialité des données des patients ;
• la transparence et la responsabilité des fonctionnalités d'IA ;
• la minimisation des données ;
• la conservation et la suppression fondées sur le consentement du patient ;
• un stockage sur le cloud respectant des normes de sécurité élevées ;
• une politique de signalement des incidents et des violations de données ;
• l'atténuation des cybermenaces.

Le titulaire doit également s'engager à ce que les données de sortie du logiciel puissent être intégrées au Système national d'information sanitaire (SIKN) ou à SATUSEHAT. En cas d'intégration, le produit doit être conçu comme un système ouvert, prendre en charge les normes d'interopérabilité applicables et être en mesure de se connecter à la plateforme nationale d'échange de données de santé.

Surveillance après commercialisation

Le ministre supervise les dispositifs à base de logiciel. L'une des voies repose sur les rapports transmis par les entreprises, qui comprennent :

• le traitement des réclamations, couvrant les événements indésirables et les mesures correctives de sécurité sur le terrain (FSCA) ;
• la surveillance technique, couvrant les vulnérabilités de cybersécurité ;
• la validation des performances cliniques après commercialisation à l'aide de données pertinentes, y compris des données en vie réelle.

Lorsque la surveillance met en évidence un risque, les mesures correctives peuvent inclure des avertissements de sécurité et/ou le rappel du produit. Les dossiers de surveillance doivent être tenus à disposition pour les besoins du contrôle. La surveillance comprend également des inspections de routine sur le terrain une fois par an ainsi que des inspections ponctuelles en cas de besoin.

Ce que cela implique pour les fabricants

Analyse de Pure Global :

• Classifier d'abord le logiciel. Utiliser l'arbre de décision du guide pour déterminer si le logiciel est un SiMD, un SaMD ou s'il n'est pas un dispositif médical. Un SiMD est enregistré en tant qu'accessoire du dispositif principal et suit ses exigences ainsi que sa classe de risque. Le guide lui-même ne fixe aucune règle relative aux classes de risque des SaMD.
• Faire correspondre le SaMD au tableau des preuves cliniques. Le tableau 3.2 utilise les deux mêmes axes que le cadre de catégorisation du risque des SaMD de l'IMDRF (N12) : l'état de la situation de soins et l'importance de l'information. Un fabricant ayant déjà catégorisé son logiciel selon le document N12 peut situer son positionnement. Un essai clinique n'est mentionné que dans la colonne « traiter ou diagnostiquer ». La nécessité d'un essai dépend également du caractère bien établi ou novateur des preuves, ainsi que de toute nouvelle allégation clinique.
• IA importée à risque modéré à élevé (en particulier pour le diagnostic, le dépistage ou les décisions cliniques) : planifier la validation clinique locale avant le lancement. Elle peut se dérouler parallèlement à la demande, mais le délai d'un an débute dès la délivrance de l'autorisation de mise sur le marché ; il convient donc d'organiser précocement le choix des sites et l'accès aux données. Le guide ne précisant pas quelles classes de risque sont considérées comme modérées à élevées, il convient de le confirmer auprès du ministère. Pour tout logiciel importé, un développement complémentaire ou un réentraînement sur des données représentatives de la population indonésienne constitue en soi un critère de validation locale.
• Gestion des versions : ajouter une vérification de l'impact pour l'Indonésie au processus de publication des versions logicielles. Les modifications d'algorithme affectant la fonction diagnostique ou thérapeutique ou les performances cliniques, l'ajout ou la suppression d'alarmes affectant la prise en charge des patients, ainsi que les modifications du système d'exploitation ou de l'infrastructure susceptibles d'affecter les performances ou la sécurité nécessitent tous une nouvelle autorisation de mise sur le marché, et non une simple modification de l'autorisation existante. Chaque modification doit être documentée dans le système de gestion de la qualité, et la version doit figurer sur l'étiquette et/ou l'interface. Enregistrer une catégorie de modification indonésienne pour chaque version permet ainsi d'associer la voie réglementaire à la version vue par les utilisateurs.
• Développement et cycle de vie de l'IA : les dix principes de GMLP que le titulaire doit appliquer s'alignent sur les dix principes directeurs du document GMLP de l'IMDRF (N88, 2025), bien que le décret ne cite pas le document N88. Les travaux relatifs aux GMLP menés pour d'autres marchés constituent un point de départ raisonnable, mais le décret ne précise pas comment la conformité doit être démontrée. Les jeux de données doivent être représentatifs de la population de patients visée, et la validation locale ainsi que le bac à sable font référence aux performances au sein de la population indonésienne. Il faut s'attendre à des questions sur la représentativité indonésienne.
• Produits déjà enregistrés ou en cours d'examen : le décret est entré en vigueur le 7 septembre 2026 et ne comporte aucune disposition transitoire. Confirmer auprès du ministère de la Santé la manière dont il s'applique aux demandes en cours ainsi qu'à la prochaine modification ou au prochain renouvellement des enregistrements existants. Ne pas présumer que la documentation antérieure reste suffisante.

La page sur le marché indonésien de Pure Global couvre la voie d'enregistrement générale. Notre étude sur l'IA en tant que dispositif médical et l'accès au marché mondial compare la manière dont d'autres organismes de réglementation traitent les logiciels d'IA.