Guia CDSCO de Software 2026: Mapa MDR 2017

A Central Drugs Standard Control Organization (CDSCO) da Índia publicou seu atual Documento de Orientação sobre Software para Dispositivos Médicos em 21 de julho de 2026. O documento de 62 páginas, numerado CDSCO/MD/GD/MDSW/01/2026, reúne a abordagem atual da CDSCO para software de dispositivos médicos (MDSW), incluindo software de diagnóstico in vitro (IVD), em uma referência operacional sob as Medical Devices Rules, 2017 (MDR 2017).

O status importa. A CDSCO afirma que o documento de orientação reflete as práticas atuais sob as MDR 2017 e “não deve ser interpretado erroneamente como um novo controle regulatório.” Trata-se de uma orientação para conscientização pública, não de um novo regulamento ou substituto para a Drugs and Cosmetics Act, as MDR 2017 ou esclarecimentos posteriores da CDSCO. Portanto, a mudança prática não é uma nova lei de software; é um mapa muito mais claro de como a CDSCO espera que o arcabouço existente seja aplicado a submissões de software, licenciamento, sistemas de qualidade, alterações e controles pós-mercado.

Leia a página oficial de avisos sobre dispositivos médicos da CDSCO ou abra o PDF completo do documento de orientação.

Quais softwares estão no escopo

O documento de orientação se aplica quando o software, por si só ou em combinação com outro produto, possui finalidade médica e atende à definição de dispositivo médico sob a legislação indiana. A CDSCO utiliza MDSW como um termo abrangente que também inclui software para dispositivos médicos de IVD, a menos que o documento especifique o contrário.

A finalidade pretendida é a linha divisória. A CDSCO exclui softwares utilizados apenas para bem-estar geral, promoção de estilo de vida saudável, monitoramento de rotina de parâmetros corporais ou condicionamento físico, desde que não sejam destinados a uma finalidade médica. Uma rotulagem de bem-estar não neutraliza alegações diagnósticas, de monitoramento, predição, tratamento ou outras alegações médicas. Os fabricantes devem, portanto, reconciliar a declaração de finalidade pretendida no produto, na submissão, na rotulagem, nas instruções de uso e no material promocional antes de confiar na exclusão.

O documento é relevante para mais do que apenas aplicativos autônomos. Seus exemplos e seções de submissão abrangem software que opera de forma independente, software que aciona ou influencia hardware, sistemas conectados à nuvem ou em rede, funções de IA/ML e software para IVD. Ele foi elaborado para fabricantes, importadores, inovadores, pesquisadores e outros requerentes que buscam aprovações regulatórias.

A classificação ainda começa com a finalidade pretendida

O MDSW segue as quatro classes de risco já utilizadas pelas MDR 2017:

A CDSCO estabelece que a classificação de software baseia-se fundamentalmente na finalidade pretendida e nas regras de classificação do Primeiro Anexo das MDR 2017. Quando mais de uma regra se aplica, prevalece a regra mais rígida que resulta na classe mais alta. O documento de orientação fornece ilustrações práticas, mas elas não substituem uma justificativa de classificação específica para o produto.

Para um portfólio de software, a unidade de análise útil não é, portanto, a base de código ou a plataforma comercial. É cada finalidade pretendida regulada e o dano que poderia decorrer das informações ou do controle fornecido pela função. Dois módulos que compartilham a mesma arquitetura técnica podem necessitar de tratamento regulatório diferente se suas finalidades médicas e riscos diferirem.

A via de submissão e a autoridade licenciadora

O documento de orientação separa a via on-line por tipo de solicitação:

• Licenças de teste: submeter por meio do National Single Window System da Índia.
• Outras autorizações regulatórias, licenças de fabricação ou importação e registro para venda e distribuição: submeter por meio do Online System for Medical Devices.

A responsabilidade pelo licenciamento também muda de acordo com a transação e a classe de risco. A Tabela 5 da CDSCO atribui as licenças de teste e licenças de importação à Autoridade Central de Licenciamento (CLA) para todas as classes. As licenças de fabricação para MDSW de Classe A e B cabem à Autoridade Estadual de Licenciamento (SLA), enquanto as licenças de fabricação de Classe C e D cabem à CLA. Dispositivos de Classe A não estéreis e sem função de medição estão isentos de licenciamento e exigem registro sob o Capítulo IIIB das MDR 2017; essa isenção não deve ser generalizada para outras configurações de software de Classe A sem a verificação das condições aplicáveis.

Essa divisão é operacionalmente importante para empresas com fabricação indiana e produtos importados. A “submissão à CDSCO” não é uma via única e indiferenciada: o portal, o formulário, a autoridade e o dossiê corretos dependem do que o requerente está solicitando permissão para fazer.

O que o dossiê agora mapeia em um só lugar

As Seções 12.1–12.5 e o Anexo A organizam as evidências esperadas em licenças de teste, investigações clínicas ou avaliações de desempenho de IVD, autorizações de dispositivos investigacionais, licenças comerciais de fabricação/importação e obrigações pós-mercado. A aplicabilidade ainda depende do produto e da solicitação, mas o documento de orientação torna visíveis os principais domínios de evidência:

• finalidade pretendida, indicações, usuários-alvo, ambiente de uso, entradas, saídas, contraindicações e limitações;
• descrição do dispositivo, arquitetura do software, versionamento, interfaces, dependências e a relação entre o software e qualquer hardware;
• justificativa de classificação e, quando aplicável, comparação com dispositivo predicado;
• ciclo de vida de desenvolvimento de software, requisitos, projeto, verificação, validação, configuração, defeitos e registros de gerenciamento de mudanças;
• gerenciamento de riscos abrangendo riscos clínicos, de usabilidade, de dados, de segurança cibernética, de interoperabilidade e relacionados à IA, quando aplicável;
• evidências clínicas ou de desempenho adequadas ao software e à via regulatória;
• rotulagem, informações eletrônicas, instalação, manutenção, atualização e informações de rastreabilidade de versão;
• evidências de SGQ para locais de fabricação nacionais ou no exterior; e
• vigilância pós-mercado, tecnovigilância, ação corretiva, recolhimento e ações de campo específicas para software.

O Anexo A transforma esses domínios em listas de verificação para a solicitação. Ele também estabelece que, quando um documento listado não for aplicável, o requerente deve fornecer uma justificativa detalhada em vez de omiti-lo silenciosamente.

SGQ, normas, segurança cibernética e alterações de software

A CDSCO insere os controles do ciclo de vida do software no sistema de gestão da qualidade. Os fabricantes nacionais devem estabelecer e manter procedimentos e registros de SGQ e enviar o termo de compromisso de conformidade com o Quinto Anexo das MDR 2017 juntamente com a solicitação de licença de fabricação. Para importações, o fabricante no exterior deve instruir a solicitação de licença de importação com as evidências de SGQ descritas no documento de orientação.

A seção de normas preserva a hierarquia das MDR 2017: primeiro as normas BIS aplicáveis ou normas indianas notificadas; em seguida, normas ISO, IEC ou outras normas internacionais declaradas quando uma norma indiana não estiver disponível; e normas validadas do fabricante quando nenhuma destas estiver especificada. Sua tabela ilustrativa de MDSW inclui ISO 13485, ISO 14971, IEC 62304, IEC 82304-1 e IEC 81001-5-1, entre outras. A tabela indica que as normas “podem ser aplicáveis”; não se trata de uma declaração de que cada norma listada se aplica de forma idêntica a todos os produtos.

Para a segurança do ciclo de vida, a CDSCO estabelece que os fabricantes devem manter e atualizar periodicamente uma lista de materiais, incluindo uma lista de materiais de software (SBOM), cobrindo componentes de terceiros, de código aberto e comerciais, conforme apropriado. O documento de orientação conecta a SBOM ao monitoramento, avaliação e mitigação de vulnerabilidades conhecidas. Ele também exige o monitoramento documentado do desempenho pós-implantação, incluindo degradação clinicamente significativa, desvio de algoritmo, vulnerabilidades de segurança cibernética e resultados não intencionais.

A redação referente ao planejamento de alterações de IA requer atenção. O documento de orientação indica que um Protocolo de Alteração de Algoritmo (ACP) pode ser elaborado, sempre que aplicável, com base na natureza e nos riscos do MDSW. Portanto, o ACP não é apresentado como um artefato obrigatório para todos os dispositivos de software. Onde for utilizado, ele deve descrever procedimentos destinados a garantir que as alterações não comprometam a segurança nem a finalidade pretendida, incluindo dados relevantes, validação, risco, monitoramento e controles de reversão.

As obrigações pós-mercado dependem do risco e da via regulatória

A aprovação comercial não encerra o ciclo de vida do software. O documento de orientação conecta as condições de licença, notificação de eventos adversos, ações corretivas de segurança em campo, recolhimentos, atualizações e rastreabilidade de versão ao arcabouço pós-mercado existente das MDR 2017. Para software, um recolhimento pode incluir a interrupção da distribuição, desinstalação ou desativação do produto em canais, redes ou hardware.

A declaração sobre o Relatório Periódico de Atualização de Segurança (PSUR) é mais restrita do que uma regra geral para todo MDSW. A CDSCO afirma especificamente que o MDSW aprovado para comercialização após investigações clínicas — como um dispositivo sem equivalente/predicado — deve ser monitorado de perto e que o fabricante ou importador deve fornecer PSURs sob as condições estabelecidas nas MDR 2017. As equipes devem mapear a obrigação pós-mercado exata conforme a via de aprovação e as condições da licença, em vez de copiar uma periodicidade universal de outro produto.

O que fabricantes e importadores devem fazer agora

A visão da Pure Global é que a resposta mais útil é uma avaliação de lacunas controlada, não uma reformulação completa baseada na palavra “guia”.

1. Substituir a versão preliminar no arquivo de inteligência regulatória. Registrar o número do documento de 21 de julho de 2026 e arquivar o guia emitido como a referência atual.
2. Conciliar a finalidade de uso e a classificação. Confirmar que as alegações do produto, os limites dos módulos, as regras de classificação e a análise da regra aplicável de maior grau de risco estejam de acordo.
3. Confirmar a via específica da transação. Separar as atividades de teste, fabricação, importação, investigação clínica e registro comercial e mapear cada uma para o portal, formulário e autoridade licenciadora corretos.
4. Fazer a correspondência cruzada do dossiê com as Seções 12 e o Anexo A. Identificar evidências ausentes e documentar por que um item da lista de verificação não é aplicável.
5. Testar o SGQ em relação à realidade do software. Confirmar que os registros de ciclo de vida, risco, configuração, verificação/validação, vulnerabilidade, SBOM, monitoramento e alterações existam como evidências controladas, e não como artefatos de engenharia fora do SGQ.
6. Definir o limite de alteração antes do próximo lançamento. Determinar quais alterações exigem validação, documentação e avaliação regulatória, e se um ACP é útil para a função específica de IA/ML.
7. Alinhar os dados pós-mercado às versões. Reclamações, eventos adversos, desvio de desempenho, vulnerabilidades, correções e recolhimentos devem permanecer rastreáveis até a versão do software efetivamente implantada.

Para a via de registro indiana mais ampla, consulte o guia de acesso ao mercado de dispositivos médicos da Índia da Pure Global. Para uma visão entre mercados de como o software habilitado para IA é classificado e mantido, consulte IA como Dispositivo Médico: O Mapa Global de Regulação, Registro e Acesso ao Mercado.

A principal conclusão é precisa: a CDSCO não anunciou um novo regime de software separado. Ela publicou o relato consolidado mais claro até o momento sobre como o software para dispositivos médicos se enquadra no sistema MDR 2017 existente na Índia. O valor para a conformidade regulatória vem do uso desse mapa para expor inconsistências antes que elas apareçam em uma solicitação de licença, lançamento de software ou evento pós-mercado.