Indonesia KMK 951/2026: registro de dispositivos médicos de software

El Ministro de Salud de Indonesia ha emitido el Decreto N.° HK.01.07/MENKES/951/2026 sobre la Guía para la Autorización de Comercialización de Dispositivos Médicos Basados en Software (Kepmenkes/KMK 951/2026). El decreto fue firmado el 7 de septiembre de 2026 y entró en vigor el mismo día. Adopta la guía en su anexo como referencia (acuan) para el gobierno, las empresas de dispositivos médicos y otras partes interesadas que gestionan la autorización de comercialización (izin edar) de dispositivos basados en software. La guía se describe a sí misma como una explicación técnica de los requisitos y procedimientos para la autorización de comercialización. Donde este artículo dice "debe", la guía en sí utiliza una redacción obligatoria (wajib o harus) o incluye el elemento entre las obligaciones (kewajiban) del titular. El decreto no contiene disposiciones transitorias para los productos que ya están registrados o que tienen solicitudes en revisión.

Alcance

La guía abarca tres grupos de productos:

• Software como dispositivo médico (SaMD): software independiente con una finalidad médica que no forma parte de un dispositivo médico de hardware. Esto incluye software para dispositivos de diagnóstico in vitro (IVD) y software que se ejecuta en plataformas de uso general como computadoras, tabletas y teléfonos inteligentes. El software que solo comanda o controla otro dispositivo médico no es SaMD. Los ejemplos de la guía son una aplicación de monitoreo de glucosa, un algoritmo que predice el riesgo de infarto de miocardio a partir de datos digitales de ECG, software de visualización de rayos X en una estación de trabajo general y una aplicación remota de signos vitales.
• Software en un dispositivo médico (SiMD): software integrado en un dispositivo que respalda su funcionamiento. Sus funciones incluyen, entre otras, operar o controlar el dispositivo, cambiar su estado o generar resultados relacionados con su función de hardware. Según el diagrama de flujo de clasificación de la guía, el SiMD se registra como un accesorio del dispositivo principal, y sus requisitos y clase de riesgo siguen a dicho dispositivo. Los ejemplos de la guía son el procesamiento de señales en escáneres de resonancia magnética (MRI) o tomografía computarizada (CT), la automatización de ventiladores, el software de imágenes por ultrasonido y el software de estimulación o desfibrilación en marcapasos e ICD.
• Dispositivos médicos con aplicaciones de inteligencia artificial: la IA, incluidos el aprendizaje automático, el procesamiento de lenguaje natural y los modelos de lenguaje de gran tamaño (LLM), es un dispositivo médico solo cuando tiene una finalidad médica. Los resultados de la IA generativa, como imágenes, texto, audio o video, están dentro del alcance cuando están destinados al diagnóstico, monitoreo, decisiones terapéuticas o atención del paciente. La IA utilizada únicamente para la gestión de datos administrativos, el almacenamiento u otras funciones operativas que no afecten el funcionamiento de un dispositivo queda excluida.

El mismo diagrama de flujo considera que el software no es un dispositivo médico cuando solo almacena, archiva, comunica, realiza búsquedas simples o aplica compresión sin pérdidas, o cuando no actúa sobre datos específicos de un paciente individual. El software que actúa sobre datos específicos del paciente tampoco es un dispositivo médico según el diagrama de flujo si no realiza ninguna de las funciones enumeradas: adquirir, procesar o analizar señales, datos de IVD, MRI, NGS, CGM o de detección/diagnóstico asistido por computadora; mostrar, analizar o imprimir señales continuas, imágenes médicas o formas de onda de ECG; o proporcionar puntuaciones de riesgo de enfermedades, probabilidades o resultados de tiempo crítico.

Fabricación, distribución y sistema de calidad

La producción es llevada a cabo por un fabricante de dispositivos médicos, que debe contar con una licencia comercial indonesia bajo el código KBLI correspondiente y cumplir con las Buenas Prácticas de Fabricación de dispositivos médicos (CPB). La distribución es llevada a cabo por un distribuidor de dispositivos médicos o su sucursal, que debe contar con una licencia comercial y cumplir con las Buenas Prácticas de Distribución (CDB). Tanto los fabricantes como los distribuidores deben aplicar un sistema de gestión de la calidad. La guía describe que un sistema de gestión de la calidad eficaz incluye el control de los procesos tercerizados, incluido el software comercial estándar (COTS), permaneciendo el propietario del producto como responsable de la seguridad y el desempeño.

Para la implementación del sistema de gestión de la calidad, la guía enumera normas que pueden utilizarse como referencias, sin ediciones. Estas incluyen ISO 13485, ISO 14971, IEC 60601-1 e IEC 61010-1 (que el decreto etiqueta como normas ISO), IEC 62366-1, IEC 62304, IEC 82304, IEC 63450, IEC 63521 y ISO 27001.

Documentos de registro

Verificación y validación de software. Estos documentos deben seguir el ciclo de vida de desarrollo de software bajo la norma IEC 62304 o una norma reconocida equivalente. Como mínimo, deben cubrir la versión del software, la trazabilidad, el control de cambios, la interoperabilidad y la ciberseguridad. Si la versión probada difiere de la versión presentada, el solicitante debe proporcionar una comparación de versiones con justificación. Se requiere una validación adicional cuando existan cambios significativos que puedan afectar la seguridad, el desempeño o el uso previsto. La versión comercializada del software debe figurar en la etiqueta del dispositivo y/o en la interfaz del software.

Software conectado. El software conectado a otros dispositivos, sistemas externos, redes o a internet requiere más información en el expediente. Debe describir los mecanismos de intercambio de datos que protegen la confidencialidad, integridad y disponibilidad, junto con la identificación de vulnerabilidades, el análisis de riesgos, la mitigación y la evidencia de que los controles son efectivos.

Gestión de riesgos. La gestión de riesgos debe llevarse a cabo a lo largo de todo el ciclo de vida del software, tomando como referencia normas tales como ISO 14971. Cada cambio en el software debe evaluarse respecto a riesgos adicionales.

Dispositivos de IA y aprendizaje automático. El diseño, desarrollo, validación, implementación y cualquier entrenamiento o reentrenamiento de modelos de IA deben llevarse a cabo dentro del sistema de gestión de la calidad. La Tabla 3.1 de la guía establece lo que debe contener un expediente de IA/ML:

Los dispositivos que utilizan aprendizaje automático continuo también deben documentar cómo se controlan los cambios en el modelo para que no afecten la seguridad, el desempeño o el uso previsto. Esa documentación abarca la frecuencia de actualización, la detección y mitigación de anomalías, el manejo de datos del mundo real, la integridad del conjunto de datos, el control de versiones con reversión a un algoritmo anterior, la trazabilidad entre datos, entrenamiento y resultados, y una estrategia de validación continua. Los dispositivos que utilizan modelos generativos o LLM también deben describir los controles de salida, la mitigación de alucinaciones, los límites de uso y cómo se evalúan la coherencia y la exactitud de la información médica que generan durante la adaptación continua.

Evidencia clínica

La evidencia clínica puede consistir en cualquiera de los siguientes elementos:

• una revisión bibliográfica y guías de práctica clínica pertinentes;
• una comparación con software similar que ya esté en el mercado, cuando exista;
• resultados de ensayos clínicos, especialmente para respaldar nuevas afirmaciones o cambios significativos en la función clínica.

Los ensayos clínicos previos a la comercialización dependen del riesgo del dispositivo y de cuán significativa sea su información para las decisiones clínicas. La guía clasifica la evidencia clínica como bien establecida o novedosa, y esta clase se utiliza como base para decidir si se necesita evidencia adicional. La evidencia debería elegirse de manera proporcional y sin cargas indebidas. Para el software de alto riesgo, la evaluación clínica puede requerir una revisión independiente. La validación analítica y la validación clínica son obligatorias para todos los dispositivos basados en software. La validación clínica se lleva a cabo tanto antes como después de la comercialización. Un nuevo uso previsto o una nueva población objetivo requiere que se repita la evaluación clínica.

La guía presenta la Tabla 3.2 como evidencia clínica recomendada, aunque el propio título de la tabla la califica como la evidencia clínica "necesaria" para la autorización de comercialización. Está organizada según la gravedad de la situación de atención médica y la importancia de la información del software para la decisión de atención médica:

La gravedad de la situación no modifica la evidencia enumerada; solo lo hace la importancia de la información.

Validación clínica local para determinado software importado

Ciertos dispositivos basados en software importados requieren validación clínica local en Indonesia. Su propósito es demostrar que el software genera resultados clínicamente significativos para la población objetivo indonesia. Se aplica al software importado que:

• ha sido desarrollado adicionalmente y/o reentrenado utilizando datos representativos de la población indonesia; y/o
• utiliza IA con un nivel de riesgo moderado a alto, en particular para diagnóstico, tamizaje o toma de decisiones clínicas.

La validación puede llevarse a cabo en:

• hospitales, universidades o laboratorios acreditados;
• unidades técnicas del Ministerio de Salud responsables de la seguridad de equipos e instalaciones sanitarias, o de servicios de genómica biomédica y de la salud.

La unidad de biomedicina y genómica puede brindar asesoría técnica a los demás centros cuando sea necesario. La validación puede realizarse en paralelo con la solicitud de autorización de comercialización si se adjunta la evidencia clínica y de desempeño del fabricante. Los resultados deben presentarse a más tardar un año después de la emisión de la autorización de comercialización. Durante la validación, el producto puede utilizarse de forma limitada para su evaluación o bajo acuerdos específicos, siempre que no se ponga en riesgo la seguridad del paciente. Si los resultados difieren significativamente de la evidencia clínica original, se podrán tomar medidas administrativas en virtud de la normativa aplicable. La guía establece que la validación local debería ser eficiente, proporcional y basada en el riesgo, y no debería obstaculizar el acceso a la innovación.

Sandbox regulatorio y madurez tecnológica

Para el software que carezca de evidencia clínica adecuada de exactitud, precisión de interpretación, seguridad o desempeño en la población indonesia, la empresa puede realizar su propio ensayo clínico conforme a la guía de ensayos clínicos para dispositivos médicos. Como alternativa, puede llevar a cabo pruebas limitadas a través de un sandbox regulatorio según la normativa aplicable. La misma sección establece que los productos de innovación en salud digital que soliciten autorización de comercialización como dispositivos médicos deben haber alcanzado el Nivel de Madurez Tecnológica (TKT) 9. TKT 9 significa que se ha demostrado que el sistema opera con éxito en su entorno operativo real, de conformidad con su uso previsto. La guía no define "producto de innovación en salud digital" ni establece si este requisito se aplica más allá de los productos del sandbox.

Rotulado

El rotulado puede adoptar la forma de una etiqueta, instrucciones de uso, una guía de operación u otra información pertinente. Como mínimo, debe identificar el nombre del producto, el número de versión del software y el propietario del producto. Asimismo, debe indicar con claridad el uso previsto, las instrucciones, la información de desempeño y la información de seguridad, incluidas las advertencias. El software suministrado en medios físicos (CD, DVD o USB) requiere una etiqueta física e instrucciones de uso, ya sea impresas o mediante un enlace. El software descargable o basado en la web debe registrarse con capturas de pantalla de la interfaz, como una pantalla de inicio o un folleto, que muestren los elementos de identificación y el número de versión. También se debe proporcionar a los usuarios el enlace de descarga, el procedimiento de descarga, la guía de instalación y el procedimiento de operación.

Cambios posteriores a la aprobación

La guía divide los cambios en un dispositivo basado en software aprobado en dos categorías, más una regla subsidiaria:

Cada cambio debe documentarse en el sistema de gestión de la calidad.

Obligaciones del titular de la autorización de comercialización

El titular debe observar principios éticos para los dispositivos basados en software:

• inclusividad y no discriminación;
• seguridad y protección;
• humanidad;
• accesibilidad;
• transparencia;
• credibilidad y rendición de cuentas;
• protección de datos personales;
• sostenibilidad;
• propiedad intelectual.

Los incidentes de protección de datos deben reportarse conforme a la normativa aplicable. Para los dispositivos con IA/ML, las Buenas Prácticas de Aprendizaje Automático (GMLP) son obligatorias con arreglo a diez principios. Estos abarcan desde el uso previsto y la experiencia multidisciplinaria hasta el monitoreo poscomercialización y la gestión de cambios, incluidos los riesgos de las actualizaciones y el reentrenamiento. Para el software con IA/ML, la gestión de datos debe seguir principios que incluyen:

• seguridad y privacidad de los datos del paciente;
• transparencia y rendición de cuentas de las funciones de IA;
• minimización de datos;
• retención y eliminación basadas en el consentimiento del paciente;
• almacenamiento en la nube con altos estándares de seguridad;
• una política de notificación de incidentes y brechas de seguridad de datos;
• mitigación de amenazas cibernéticas.

El titular también debe comprometerse a que los datos de salida del software puedan integrarse con el Sistema Nacional de Información de Salud (SIKN) o SATUSEHAT. En caso de integrarse, el producto debe estar diseñado como un sistema abierto, admitir los estándares de interoperabilidad aplicables y ser capaz de conectarse a la plataforma nacional de intercambio de datos de salud.

Supervisión poscomercialización

El Ministro supervisa los dispositivos basados en software. Una de las vías son los informes de las empresas, que incluyen:

• gestión de quejas, que abarca eventos adversos y acciones correctivas de seguridad en campo (FSCA);
• monitoreo técnico, que cubre vulnerabilidades de ciberseguridad;
• validación del desempeño clínico poscomercialización mediante datos pertinentes, incluidos datos del mundo real.

Cuando el monitoreo indique un riesgo, las medidas correctivas pueden incluir advertencias de seguridad y/o el retiro del producto del mercado. Los registros de monitoreo deben mantenerse a disposición para su supervisión. La supervisión también incluye inspecciones de campo de rutina una vez al año e inspecciones extraordinarias cuando sea necesario.

Qué significa esto para los fabricantes

Análisis de Pure Global:

• Clasifique el software primero. Utilice el diagrama de flujo de la guía para determinar si el software es SiMD, SaMD o no es un dispositivo médico. El SiMD se registra como un accesorio del dispositivo principal y sigue sus requisitos y clase de riesgo. La guía en sí no establece reglas para las clases de riesgo del SaMD.
• Asocie el SaMD a la tabla de evidencia clínica. La Tabla 3.2 utiliza los mismos dos ejes que el marco de categorización de riesgo para SaMD del IMDRF (N12): el estado de la situación de atención médica y la importancia de la información. Un fabricante que ya haya categorizado su software conforme a N12 puede identificar en qué posición se ubica. El ensayo clínico figura únicamente en la columna "tratar o diagnosticar". La necesidad de un ensayo también depende de si la evidencia está bien establecida o es novedosa, así como de cualquier nueva afirmación clínica.
• IA importada de riesgo moderado a alto (en particular para diagnóstico, tamizaje o decisiones clínicas): planifique la validación clínica local antes del lanzamiento. Puede llevarse a cabo en paralelo con la solicitud, pero el plazo límite de un año comienza al momento en que se emite la autorización de comercialización, por lo que se recomienda gestionar los centros y el acceso a los datos con anticipación. La guía no especifica qué clases de riesgo se consideran de moderado a alto, por lo que conviene confirmarlo con el Ministerio. Para cualquier software importado, el desarrollo adicional o el reentrenamiento con datos representativos de la población indonesia constituye por sí mismo un criterio para la validación local.
• Gestión de versiones: incorpore una verificación de impacto para Indonesia en el proceso de lanzamiento del software. Los cambios en el algoritmo que afecten la función diagnóstica o terapéutica o el desempeño clínico, la adición o eliminación de alarmas que afecten el manejo del paciente, y las modificaciones en el sistema operativo o en la infraestructura que puedan afectar el desempeño o la seguridad requieren una nueva autorización de comercialización, no una modificación de la existente. Cada cambio debe documentarse en el sistema de gestión de la calidad, y la versión debe figurar en la etiqueta y/o en la interfaz. Por lo tanto, registrar una categoría de cambio para Indonesia en cada lanzamiento vincula la vía regulatoria con la versión que ven los usuarios.
• Desarrollo y ciclo de vida de la IA: los diez principios de GMLP que el titular debe aplicar se alinean con los diez principios rectores del documento de GMLP del IMDRF (N88, 2025), aunque el decreto no cita a N88. El trabajo de GMLP realizado para otros mercados es un punto de partida razonable, pero el decreto no especifica cómo debe demostrarse el cumplimiento. Los conjuntos de datos deben representar a la población de pacientes prevista, y la validación local y el sandbox hacen referencia al desempeño en la población indonesia. Prevea preguntas sobre la representatividad respecto a la población indonesia.
• Productos ya registrados o en proceso de revisión: el decreto entró en vigor el 7 de septiembre de 2026 y no cuenta con disposiciones transitorias. Confirme con el Ministerio de Salud cómo se aplica a las solicitudes pendientes y a la próxima modificación o renovación de registros existentes. No asuma que la documentación previa continuará siendo suficiente.

La página del mercado de Indonesia de Pure Global describe la vía general de registro. Nuestra investigación sobre la IA como dispositivo médico y acceso al mercado global compara cómo otros organismos reguladores abordan el software con IA.