Indonesia KMK 951/2026: autorizzazione dei dispositivi medici software

Il Ministro della Salute indonesiano ha emanato il Decreto n. HK.01.07/MENKES/951/2026 relativo alle linee guida per l'autorizzazione all'immissione in commercio dei dispositivi medici basati su software (Kepmenkes/KMK 951/2026). Il decreto è stato firmato il 7 settembre 2026 ed è entrato in vigore il giorno stesso. Esso adotta le linee guida contenute nel suo allegato come riferimento (acuan) per il governo, le imprese di dispositivi medici e gli altri stakeholder che gestiscono l'autorizzazione all'immissione in commercio (izin edar) dei dispositivi basati su software. Le linee guida si descrivono come una spiegazione tecnica dei requisiti e delle procedure per l'autorizzazione all'immissione in commercio. Laddove il presente articolo riporta "deve", le linee guida stesse utilizzano una formulazione vincolante (wajib o harus) o includono la voce tra gli obblighi (kewajiban) del titolare. Il decreto non contiene alcuna disposizione transitoria per i prodotti già registrati o che abbiano domande in corso di valutazione.

Ambito di applicazione

Le linee guida coprono tre gruppi di prodotti:

• Software as a Medical Device (SaMD): software stand-alone con una destinazione d'uso medica che non fa parte di un dispositivo medico hardware. Include software per dispositivi diagnostici in vitro (IVD) e software eseguito su piattaforme per uso generale quali computer, tablet e smartphone. Il software che si limita a guidare o controllare un altro dispositivo medico non è un SaMD. Gli esempi forniti dalle linee guida sono un'app per il monitoraggio del glucosio, un algoritmo che prevede il rischio di infarto a partire da dati ECG digitali, un software per la visualizzazione di radiografie su una workstation generica e un'app per il rilevamento remoto dei parametri vitali.
• Software in a Medical Device (SiMD): software incorporato in un dispositivo che ne supporta il funzionamento. Le sue funzioni includono, a titolo esemplificativo ma non esaustivo, l'azionamento o il controllo del dispositivo, la modifica del suo stato o la produzione di output correlati alla sua funzione hardware. In base al diagramma di flusso di classificazione delle linee guida, il SiMD è registrato come accessorio del dispositivo principale, e i suoi requisiti e la sua classe di rischio seguono quelli di tale dispositivo. Gli esempi forniti dalle linee guida sono l'elaborazione dei segnali in scanner RM o TC, l'automazione dei ventilatori polmonari, il software per l'imaging a ultrasuoni e il software di stimolazione o defibrillazione in pacemaker e ICD.
• Dispositivi medici con applicazioni di intelligenza artificiale: l'IA, inclusi l'apprendimento automatico (machine learning), l'elaborazione del linguaggio naturale (natural language processing) e i modelli linguistici di grandi dimensioni (LLM), è un dispositivo medico solo quando ha una destinazione d'uso medica. Gli output dell'IA generativa quali immagini, testo, audio o video rientrano nell'ambito di applicazione quando sono destinati a diagnosi, monitoraggio, decisioni terapeutiche o assistenza al paziente. L'IA utilizzata unicamente per la gestione amministrativa dei dati, l'archiviazione o altre funzioni operative che non incidono sul funzionamento del dispositivo è esclusa.

Il medesimo diagramma di flusso non considera il software come un dispositivo medico quando si limita a memorizzare, archiviare, comunicare, eseguire ricerche semplici o applicare una compressione senza perdita di dati (lossless), oppure quando non agisce su dati specifici di un singolo paziente. Anche il software che agisce su dati specifici del paziente non è un dispositivo medico ai sensi del diagramma di flusso se non esegue alcuna delle funzioni elencate: acquisire, elaborare o analizzare segnali, dati IVD, RM, NGS, CGM o di rilevamento/diagnosi assistita da computer; visualizzare, analizzare o stampare segnali continui, immagini mediche o forme d'onda ECG; oppure fornire punteggi di rischio patologico, probabilità o output critici in termini di tempo.

Fabbricazione, distribuzione e sistema di qualità

La produzione è effettuata da un fabbricante di dispositivi medici, che deve essere in possesso di una licenza commerciale indonesiana con il relativo codice KBLI e soddisfare le Buone Pratiche di Fabbricazione per i dispositivi medici (CPB). La distribuzione è effettuata da un distributore di dispositivi medici o da una sua filiale, che deve essere in possesso di una licenza commerciale e rispettare le Buone Pratiche di Distribuzione (CDB). Sia i fabbricanti sia i distributori devono applicare un sistema di gestione della qualità. Le linee guida descrivono un sistema di gestione della qualità efficace come comprensivo del controllo dei processi esternalizzati, compreso il software commerciale pronto all'uso (COTS), con il proprietario del prodotto che rimane responsabile della sicurezza e delle prestazioni.

Per l'implementazione del sistema di gestione della qualità, le linee guida elencano norme che possono essere utilizzate come riferimento, senza specificarne le edizioni. Tra queste figurano ISO 13485, ISO 14971, IEC 60601-1 e IEC 61010-1 (che il decreto indica come norme ISO), IEC 62366-1, IEC 62304, IEC 82304, IEC 63450, IEC 63521 e ISO 27001.

Documenti di registrazione

Verifica e convalida del software. Tali documenti devono seguire il ciclo di vita dello sviluppo del software ai sensi della norma IEC 62304 o di una norma riconosciuta equivalente. Come minimo, devono riguardare la versione del software, la tracciabilità, il controllo delle modifiche, l'interoperabilità e la cybersicurezza. Qualora la versione testata differisca dalla versione presentata, il richiedente deve fornire un confronto tra le versioni corredato di motivazione. È richiesta un'ulteriore convalida in caso di modifiche significative che possano incidere sulla sicurezza, sulle prestazioni o sulla destinazione d'uso. La versione commercializzata del software deve figurare sull'etichetta del dispositivo e/o sull'interfaccia del software.

Software connesso. Il software connesso ad altri dispositivi, sistemi esterni, reti o a Internet richiede un maggior numero di informazioni nel dossier. Deve descrivere i meccanismi di scambio dati che tutelano riservatezza, integrità e disponibilità, unitamente all'identificazione delle vulnerabilità, all'analisi dei rischi, alla mitigazione e all'evidenza che i controlli siano efficaci.

Gestione del rischio. La gestione del rischio deve estendersi all'intero ciclo di vita del software, facendo riferimento a norme quali ISO 14971. Ogni modifica apportata al software deve essere valutata per rilevare eventuali rischi aggiuntivi.

Dispositivi con IA e machine learning. La progettazione, lo sviluppo, la convalida, l'implementazione operativa e qualsiasi addestramento o riaddestramento dei modelli di IA devono svolgersi all'interno del sistema di gestione della qualità. La Tabella 3.1 delle linee guida definisce cosa deve contenere un dossier AI/ML:

I dispositivi che utilizzano l'apprendimento automatico continuo devono inoltre documentare in che modo le modifiche al modello vengano controllate affinché non incidano sulla sicurezza, sulle prestazioni o sulla destinazione d'uso. Tale documentazione riguarda la frequenza di aggiornamento, il rilevamento e la mitigazione delle anomalie, la gestione dei dati del mondo reale (real-world data), l'integrità dei dataset, il controllo di versione con possibilità di ripristino (rollback) a un algoritmo precedente, la tracciabilità tra dati, addestramento e output, nonché una strategia di convalida continua. I dispositivi che impiegano modelli generativi o LLM devono altresì descrivere i controlli degli output, la mitigazione delle allucinazioni, i limiti di utilizzo e le modalità con cui la coerenza e l'accuratezza delle informazioni mediche generate vengono valutate durante l'adattamento continuo.

Evidenze cliniche

Le evidenze cliniche possono consistere in uno qualsiasi dei seguenti elementi:

• una revisione della letteratura e linee guida di pratica clinica pertinenti;
• un confronto con software analoghi già presenti sul mercato, ove esistenti;
• risultati di studi clinici, in particolare a supporto di nuovi claim o di modifiche significative della funzione clinica.

Gli studi clinici pre-commercializzazione dipendono dal rischio del dispositivo e da quanto le sue informazioni siano determinanti per le decisioni cliniche. Le linee guida classificano le evidenze cliniche come consolidate o innovative, e tale classe è utilizzata come base per decidere se siano necessarie ulteriori evidenze. Le evidenze dovrebbero essere selezionate in modo proporzionato e senza oneri indebiti. Per i software ad alto rischio, la valutazione clinica può richiedere una revisione indipendente. La convalida analitica e la convalida clinica sono richieste per tutti i dispositivi basati su software. La convalida clinica si svolge sia prima sia dopo l'immissione in commercio. Una nuova destinazione d'uso o una nuova popolazione target richiede la ripetizione della valutazione clinica.

Le linee guida introducono la Tabella 3.2 come evidenze cliniche raccomandate, sebbene il titolo stesso della tabella le definisca come le evidenze cliniche "necessarie" per l'autorizzazione all'immissione in commercio. Essa è strutturata in base alla gravità della situazione sanitaria e alla rilevanza delle informazioni del software per la decisione sanitaria:

La gravità della situazione non modifica le evidenze elencate; lo fa unicamente la rilevanza delle informazioni.

Validazione clinica locale per determinati software importati

Determinati dispositivi basati su software importati richiedono una validazione clinica locale in Indonesia. Il suo scopo è dimostrare che il software produce un output clinicamente significativo per la popolazione target indonesiana. Si applica ai software importati che:

• sono stati ulteriormente sviluppati e/o riaddestrati utilizzando dati rappresentativi della popolazione indonesiana; e/o
• utilizzano l'IA con un livello di rischio da moderato ad alto, in particolare per la diagnosi, lo screening o il processo decisionale clinico.

La validazione può avere luogo presso:

• ospedali, università o laboratori accreditati;
• unità tecniche del Ministero della Salute responsabili della sicurezza delle apparecchiature e delle strutture sanitarie, o dei servizi di genomica biomedica e sanitaria.

L'unità biomedica e genomica può fornire tutoraggio agli altri centri, ove necessario. La validazione può svolgersi in parallelo alla domanda di autorizzazione all'immissione in commercio qualora siano allegate le evidenze cliniche e di prestazione del fabbricante. I risultati devono essere presentati entro e non oltre un anno dal rilascio dell'autorizzazione all'immissione in commercio. Durante la validazione, il prodotto può essere utilizzato in modo limitato a fini valutativi o nell'ambito di specifici accordi, a condizione che non sia messa a rischio la sicurezza dei pazienti. Qualora i risultati differiscano significativamente dalle evidenze cliniche originali, possono essere adottati provvedimenti amministrativi ai sensi delle normative applicabili. Le linee guida affermano che la validazione locale dovrebbe essere efficiente, proporzionata e basata sul rischio, e non dovrebbe ostacolare l'accesso all'innovazione.

Sandbox regolatoria e maturità tecnologica

Per i software che non dispongono di adeguate evidenze cliniche di accuratezza, precisione di interpretazione, sicurezza o prestazioni nella popolazione indonesiana, l'impresa può condurre una propria sperimentazione clinica ai sensi della linea guida sulle sperimentazioni cliniche dei dispositivi medici. In alternativa, può eseguire test limitati attraverso una sandbox regolatoria ai sensi delle normative applicabili. La medesima sezione stabilisce che i prodotti di innovazione per la salute digitale che richiedono l'autorizzazione all'immissione in commercio come dispositivi medici devono aver raggiunto il Technology Readiness Level (TKT) 9. Il TKT 9 indica che il sistema ha dimostrato di operare con successo nel suo effettivo ambiente operativo, in linea con la sua destinazione d'uso. Le linee guida non definiscono "prodotto di innovazione per la salute digitale" né specificano se tale requisito si applichi al di là dei prodotti della sandbox.

Etichettatura

L'etichettatura può assumere la forma di un'etichetta, delle istruzioni per l'uso, di una guida operativa o di altre informazioni pertinenti. Come requisito minimo deve identificare la denominazione del prodotto, il numero di versione del software e il proprietario del prodotto. Deve inoltre indicare chiaramente la destinazione d'uso, le istruzioni, le informazioni sulle prestazioni e le informazioni sulla sicurezza, comprese le avvertenze. Il software fornito su supporto fisico (CD, DVD o USB) richiede un'etichetta fisica e istruzioni per l'uso, in formato cartaceo o tramite link. Il software scaricato o basato sul web deve essere registrato allegando schermate dell'interfaccia, come una schermata di avvio (splash screen) o una brochure, che mostrino gli elementi identificativi e il numero di versione. Agli utenti devono essere forniti anche il link per il download, la procedura di download, la guida all'installazione e la procedura operativa.

Modifiche successive all'approvazione

Le linee guida suddividono le modifiche a un dispositivo basato su software approvato in due categorie, oltre a una regola residuale:

Ogni modifica deve essere documentata nel sistema di gestione della qualità.

Obblighi del titolare dell'autorizzazione all'immissione in commercio

Il titolare deve rispettare i principi etici per i dispositivi basati su software:

• inclusività e non discriminazione;
• sicurezza e protezione;
• umanità;
• accessibilità;
• trasparenza;
• credibilità e responsabilità;
• protezione dei dati personali;
• sostenibilità;
• proprietà intellettuale.

Gli incidenti relativi alla protezione dei dati devono essere segnalati ai sensi delle normative applicabili. Per i dispositivi con AI/ML, la Good Machine Learning Practice (GMLP) è obbligatoria in base a dieci principi. Questi spaziano dalla destinazione d'uso e dalle competenze multidisciplinari fino al monitoraggio post-commercializzazione e alla gestione delle modifiche, compresi i rischi legati ad aggiornamenti e riaddestramento. Per i software con AI/ML, la gestione dei dati deve seguire principi che comprendono:

• sicurezza e riservatezza dei dati dei pazienti;
• trasparenza e responsabilità delle funzionalità di IA;
• minimizzazione dei dati;
• conservazione e cancellazione basate sul consenso del paziente;
• archiviazione su cloud conforme a elevati standard di sicurezza;
• una politica di notifica degli incidenti e delle violazioni dei dati;
• mitigazione delle minacce informatiche.

Il titolare deve inoltre impegnarsi a garantire che i dati di output del software possano essere integrati con il Sistema Informativo Sanitario Nazionale (SIKN) o SATUSEHAT. In caso di integrazione, il prodotto deve essere progettato come un sistema aperto, supportare gli standard di interoperabilità applicabili ed essere in grado di connettersi alla piattaforma nazionale di scambio dei dati sanitari.

Sorveglianza post-commercializzazione

Il Ministro vigila sui dispositivi basati su software. Una delle modalità è costituita dalle segnalazioni delle imprese, che comprendono:

• gestione dei reclami, comprendente gli eventi avversi e le azioni correttive di sicurezza sul campo (FSCA);
• monitoraggio tecnico, comprendente le vulnerabilità di sicurezza informatica;
• validazione delle prestazioni cliniche post-commercializzazione mediante dati pertinenti, inclusi i dati del mondo reale (real-world data).

Laddove il monitoraggio evidenzi un rischio, le azioni correttive possono comprendere avvisi di sicurezza e/o il richiamo del prodotto. I registri di monitoraggio devono essere tenuti a disposizione per la vigilanza. La vigilanza comprende inoltre ispezioni sul campo di routine una volta all'anno e ispezioni straordinarie al bisogno.

Cosa significa questo per i fabbricanti

Analisi di Pure Global:

• Classificare prima il software. Utilizzare il diagramma di flusso delle linee guida per stabilire se il software sia SiMD, SaMD o non sia un dispositivo medico. Il SiMD viene registrato come accessorio del dispositivo principale e ne segue i requisiti e la classe di rischio. Le linee guida in sé non stabiliscono regole relative alla classe di rischio del SaMD.
• Mappare il SaMD sulla tabella delle evidenze cliniche. La Tabella 3.2 utilizza i medesimi due assi del quadro di categorizzazione del rischio SaMD dell'IMDRF (N12): lo stato della situazione sanitaria e la rilevanza delle informazioni. Un fabbricante che abbia già categorizzato il proprio software in base a N12 può verificare la propria collocazione. Uno studio clinico è indicato solo nella colonna "trattare o diagnosticare". La necessità di uno studio clinico dipende inoltre dal fatto che le evidenze siano consolidate o innovative, nonché da eventuali nuovi claim clinici.
• IA importata a rischio da moderato ad alto (in particolare per diagnosi, screening o decisioni cliniche): pianificare la validazione clinica locale prima del lancio. Può svolgersi parallelamente alla domanda, ma il termine di un anno decorre dal rilascio dell'autorizzazione all'immissione in commercio; pertanto, è opportuno organizzare tempestivamente i centri e l'accesso ai dati. Le linee guida non specificano quali classi di rischio siano considerate da moderate ad alte, per cui è opportuno verificarlo con il Ministero. Per qualsiasi software importato, l'ulteriore sviluppo o il riaddestramento su dati rappresentativi della popolazione indonesiana costituisce di per sé un criterio per la validazione locale.
• Gestione dei rilasci: aggiungere una verifica dell'impatto per l'Indonesia al processo di rilascio del software. Le modifiche agli algoritmi che incidono sulla funzione diagnostica o terapeutica o sulle prestazioni cliniche, l'aggiunta o la rimozione di allarmi che incidono sulla gestione del paziente e le modifiche al sistema operativo o all'infrastruttura che potrebbero incidere sulle prestazioni o sulla sicurezza richiedono tutte una nuova autorizzazione all'immissione in commercio, e non una modifica a quella esistente. Ogni modifica deve essere documentata nel sistema di gestione della qualità e la versione deve essere riportata sull'etichetta e/o sull'interfaccia. La registrazione di una categoria di modifica indonesiana per ciascun rilascio collega quindi il percorso regolatorio alla versione visualizzata dagli utenti.
• Sviluppo e ciclo di vita dell'IA: i dieci principi GMLP che il titolare deve applicare ricalcano i dieci principi guida del documento GMLP dell'IMDRF (N88, 2025), sebbene il decreto non citi N88. Il lavoro svolto sulle GMLP per altri mercati costituisce un ragionevole punto di partenza, ma il decreto non specifica come debba essere dimostrata la conformità. I set di dati devono essere rappresentativi della popolazione di pazienti a cui il dispositivo è destinato, e sia la validazione locale sia la sandbox fanno riferimento alle prestazioni nella popolazione indonesiana. È opportuno attendersi richieste di chiarimento sulla rappresentatività indonesiana.
• Prodotti già registrati o in corso di valutazione: il decreto è entrato in vigore il 7 settembre 2026 e non contiene disposizioni transitorie. Verificare con il Ministero della Salute come si applichi alle domande pendenti e alla successiva modifica o rinnovo delle registrazioni esistenti. Non dare per scontato che la documentazione precedente rimanga sufficiente.

La pagina del mercato indonesiano di Pure Global descrive il percorso di registrazione complessivo. La nostra ricerca su IA come dispositivo medico e accesso al mercato globale confronta il modo in cui le altre autorità regolatorie trattano i software di IA.