Guía Software Médico CDSCO 2026: Mapa MDR 2017

La Organización Central de Control Estándar de Medicamentos de la India (CDSCO) publicó su Documento de Orientación sobre Software de Dispositivos Médicos actual el 21 de julio de 2026. El documento de 62 páginas, numerado CDSCO/MD/GD/MDSW/01/2026, reúne el enfoque actual de la CDSCO respecto al software de dispositivos médicos (MDSW), incluido el software de diagnóstico in vitro (IVD), en una sola referencia operativa conforme a las Normas sobre Dispositivos Médicos de 2017 (MDR 2017).

El estatus es importante. La CDSCO señala que la orientación refleja las prácticas actuales conforme a las MDR 2017 y “no debe malinterpretarse como un nuevo control regulatorio.” Se trata de una guía para conocimiento público, no de una nueva regulación ni un sustituto de la Ley de Medicamentos y Cosméticos, las MDR 2017 o aclaraciones posteriores de la CDSCO. Por lo tanto, el cambio práctico no es una nueva ley de software; es un mapa mucho más claro de cómo la CDSCO espera que el marco existente se aplique a las solicitudes, licencias, sistemas de gestión de calidad, cambios y controles poscomercialización de software.

Lea la página oficial de avisos sobre dispositivos médicos de la CDSCO u abra el PDF completo de la orientación.

Qué software está dentro del alcance

La orientación se aplica cuando el software, por sí solo o en combinación con otro producto, tiene un propósito médico y cumple con la definición de dispositivo médico conforme a la legislación india. La CDSCO utiliza MDSW como un término general que también incluye el software de dispositivos médicos de IVD, a menos que el documento indique lo contrario.

El uso previsto es la línea divisoria. La CDSCO excluye el software utilizado únicamente para el bienestar general, la promoción de un estilo de vida saludable, el seguimiento rutinario de parámetros corporales o la condición física, siempre que no esté destinado a un propósito médico. Una etiqueta de bienestar no neutraliza las declaraciones de diagnóstico, monitoreo, predicción, tratamiento u otras reivindicaciones médicas. Por lo tanto, los fabricantes deben conciliar la declaración de uso previsto en el producto, la solicitud, el etiquetado, las instrucciones de uso y el material promocional antes de ampararse en dicha exclusión.

El documento es relevante para algo más que aplicaciones independientes. Sus ejemplos y secciones de presentación abordan software que opera de manera independiente, software que impulsa o influye en el hardware, sistemas conectados a la nube o a redes, funciones de IA/ML y software para IVD. Está redactado para fabricantes, importadores, innovadores, investigadores y otros solicitantes que buscan aprobaciones regulatorias.

La clasificación sigue comenzando con el uso previsto

El MDSW sigue las cuatro clases de riesgo ya utilizadas por las MDR 2017:

La CDSCO establece que la clasificación del software se basa fundamentalmente en el uso previsto y en las reglas de clasificación del Primer Anexo de las MDR 2017. Cuando se aplica más de una regla, prevalece la regla más estricta que genere la clase más alta. La orientación ofrece ilustraciones prácticas, pero estas no reemplazan la justificación de clasificación específica para un producto determinado.

Por lo tanto, para un portafolio de software, la unidad de análisis útil no es la base de código ni la plataforma comercial. Es cada propósito previsto regulado y el daño que podría derivarse de la información o el control que proporciona la función. Dos módulos que comparten la misma arquitectura técnica pueden requerir un tratamiento regulatorio diferente si sus fines médicos y riesgos difieren.

La vía de presentación y la autoridad de licencias

La orientación separa la vía en línea según el tipo de solicitud:

• Licencias de prueba: enviar a través del Sistema de Ventanilla Única Nacional de la India.
• Otras autorizaciones regulatorias, licencias de fabricación o importación y registro para venta y distribución: enviar a través del Sistema en Línea para Dispositivos Médicos.

La responsabilidad de la emisión de licencias también cambia según la transacción y la clase de riesgo. La Tabla 5 de la CDSCO asigna las licencias de prueba y las licencias de importación a la Autoridad Central de Licencias (CLA) para todas las clases. Las licencias de fabricación para MDSW de Clase A y B corresponden a la Autoridad Estatal de Licencias (SLA), mientras que las licencias de fabricación de Clase C y D corresponden a la CLA. Los dispositivos de Clase A no estériles y no de medición están exentos de licencia y requieren registro bajo el Capítulo IIIB de las MDR 2017; esa exención no debe generalizarse a otras configuraciones de software de Clase A sin verificar las condiciones aplicables.

Esta división es operacionalmente importante para las empresas que cuentan tanto con fabricación en la India como con productos importados. La «presentación ante la CDSCO» no es una vía única e indiferenciada: el portal, formulario, autoridad y expediente correctos dependen de la autorización que el solicitante esté requiriendo.

Lo que el expediente mapea ahora en un solo lugar

Las secciones 12.1–12.5 y el Anexo A organizan la evidencia que se espera en las licencias de prueba, investigaciones clínicas o evaluaciones de desempeño de IVD, autorizaciones de dispositivos en investigación, licencias comerciales de fabricación/importación y obligaciones poscomercialización. La aplicabilidad sigue dependiendo del producto y la solicitud, pero la orientación visibiliza los principales dominios de evidencia:

• uso previsto, indicaciones, usuarios de destino, entorno de uso, insumos/entradas, resultados/salidas, contraindicaciones y limitaciones;
• descripción del dispositivo, arquitectura de software, versionado, interfaces, dependencias y la relación entre el software y cualquier hardware;
• justificación de la clasificación y, cuando corresponda, comparación con el dispositivo predicho;
• ciclo de vida del desarrollo de software, requisitos, diseño, verificación, validación, configuración, registros de defectos y de gestión de cambios;
• gestión de riesgos que abarque riesgos clínicos, de usabilidad, de datos, de ciberseguridad, de interoperabilidad y relacionados con la IA, según corresponda;
• evidencia clínica o de desempeño adecuada para el software y la vía regulatoria;
• información de etiquetado, información electrónica, instalación, mantenimiento, actualización y trazabilidad de versiones;
• evidencia del SGC para sitios de fabricación nacionales o en el extranjero; y
• vigilancia poscomercialización, tecnovigilancia, acciones correctivas, retiros del mercado y acciones de campo específicas de software.

El Anexo A convierte esos dominios en listas de verificación de solicitudes. También señala que cuando un documento enumerado no sea aplicable, el solicitante debe proporcionar una justificación detallada en lugar de omitirlo en silencio.

SGC, normas, ciberseguridad y cambios de software

La CDSCO ubica los controles del ciclo de vida del software dentro del sistema de gestión de la calidad. Los fabricantes nacionales deben establecer y mantener procedimientos y registros del SGC y presentar el compromiso de cumplimiento del Quinto Anexo de las MDR 2017 junto con la solicitud de licencia de fabricación. Para las importaciones, el fabricante en el extranjero debe respaldar la solicitud de licencia de importación con la evidencia del SGC descrita en la orientación.

La sección de normas conserva la jerarquía de las MDR 2017: en primer lugar, las normas aplicables de la BIS o normas indias notificadas; luego, las normas ISO, IEC u otras normas internacionales establecidas cuando no se disponga de una norma india; y las normas validadas del fabricante cuando no se especifique ninguna de las anteriores. Su tabla ilustrativa de MDSW incluye ISO 13485, ISO 14971, IEC 62304, IEC 82304-1 e IEC 81001-5-1, entre otras. La tabla indica que las normas «pueden ser aplicables»; no es una declaración de que cada norma enumerada se aplique de manera idéntica a cada producto.

Para la seguridad del ciclo de vida, la CDSCO señala que los fabricantes deben mantener y actualizar periódicamente una lista de materiales, incluida una lista de materiales de software (SBOM), que cubra componentes de terceros, de código abierto y comerciales, según corresponda. La orientación conecta la SBOM con el monitoreo, la evaluación y la mitigación de vulnerabilidades conocidas. También requiere un monitoreo documentado del desempeño posterior a la implementación, que incluya degradación clínicamente significativa, desviación del algoritmo, vulnerabilidades de ciberseguridad y resultados no deseados.

La redacción sobre la planificación de cambios en IA requiere cuidado. La orientación señala que se puede elaborar un Protocolo de Cambio de Algoritmo (ACP), donde sea aplicable, según la naturaleza y los riesgos del MDSW. Por lo tanto, un ACP no se presenta como un artefacto obligatorio para todos los dispositivos de software. Donde se utilice, debe describir procedimientos destinados a garantizar que los cambios no comprometan la seguridad ni el uso previsto, incluidos los controles relevantes de datos, validación, riesgo, monitoreo y reversión (rollback).

Las obligaciones poscomercialización dependen del riesgo y de la vía regulatoria

La aprobación comercial no pone fin al ciclo de vida del software. La orientación vincula las condiciones de la licencia, el reporte de eventos adversos, las acciones correctivas de seguridad de campo, los retiros del mercado, las actualizaciones y la trazabilidad de versiones con el marco poscomercialización existente de las MDR 2017. En el caso del software, un retiro del mercado puede incluir la suspensión de la distribución, la desinstalación o el retiro del servicio del producto en canales, redes o hardware.

La declaración sobre el Informe Periódico de Actualización de Seguridad (PSUR) es más limitada que una regla general para todo MDSW. La CDSCO indica específicamente que el MDSW aprobado para comercialización tras investigaciones clínicas —como un dispositivo sin un predicado— debe ser monitoreado de cerca y que el fabricante o importador debe presentar informes PSUR conforme a las condiciones establecidas en las MDR 2017. Los equipos deben mapear la obligación poscomercialización exacta a la vía de aprobación y las condiciones de la licencia, en lugar de copiar una cadencia universal de otro producto.

Lo que los fabricantes e importadores deben hacer ahora

La postura de Pure Global es que la respuesta más útil es una evaluación de brechas controlada, no un rediseño total basado en la palabra “guía”.

1. Reemplazar el borrador en el archivo de inteligencia regulatoria. Registrar el número de documento de 21 de julio de 2026 y archivar la guía emitida como la referencia actual.
2. Conciliar el uso previsto y la clasificación. Confirmar que las aseveraciones del producto, los límites de los módulos, las reglas de clasificación y el análisis de la regla de mayor aplicabilidad coincidan.
3. Confirmar la ruta específica para la transacción. Separar las actividades de prueba, fabricación, importación, investigación y registro comercial, y mapear cada una al portal, formulario y autoridad de licencias correspondiente.
4. Hacer una correspondencia cruzada del expediente con las Secciones 12 y el Anexo A. Identificar la evidencia faltante y documentar por qué un elemento de la lista de verificación no es aplicable.
5. Evaluar el QMS frente a la realidad del software. Confirmar que los registros de ciclo de vida, riesgo, configuración, verificación/validación, vulnerabilidades, SBOM, monitoreo y cambios existan como evidencia controlada en lugar de artefactos de ingeniería fuera del QMS.
6. Definir el límite del cambio antes de la próxima versión. Determinar qué cambios requieren validación, documentación y evaluación regulatoria, y si un ACP es útil para la función particular de IA/ML.
7. Alinear los datos poscomercialización con las versiones. Las quejas, eventos adversos, desviación del desempeño, vulnerabilidades, correcciones y retiros del mercado deben permanecer trazables hasta la versión del software realmente desplegada.

Para conocer la vía de registro más amplia en la India, consulte la guía de acceso al mercado de dispositivos médicos de la India de Pure Global. Para obtener una visión multimercado de cómo se clasifica y mantiene el software habilitado para IA, consulte IA como dispositivo médico: el mapa global de regulación, registro y acceso al mercado.

La conclusión principal es precisa: la CDSCO no ha anunciado un régimen de software nuevo e independiente. Ha emitido la explicación consolidada más clara hasta la fecha sobre cómo encaja el software de dispositivos médicos dentro del sistema MDR 2017 existente en la India. El valor del cumplimiento radica en utilizar ese mapa para exponer inconsistencias antes de que aparezcan en una solicitud de licencia, lanzamiento de software o evento poscomercialización.