Causas e Recomendações
Um grupo de especialistas da comissões IEC/SC62A + ISO/215/JWG7 foram designados pela para determinar as causa das falha dos três projetos da 2ª dição da IEC 62304 e definir recomendações para a nova versão da norma, com o objetivo de ajudar as comissões nacionais a elaborarem uma versão mais assertiva da norma.
O projeto da 2ª edição passou por 3 CDVs* sem acordo entre a ISO e IEC, a principal disputa estava em definir quais requisitos do sistema da qualidade requerem Gerenciamento de Risco.
Com o passar do tempo outros pontos também não encontram consenso:
▫Classificação de segurança ( com base em lesão)
▫SW legado
▫Falta de provisões para novas tecnologias ( ex. IA)
O grupo recomendou que o projeto 62304 Edição 2.0 deve ter uma especificação de design com base em requisitos específicos, além de:
O projeto da 2ª edição passou por 3 CDVs (Committee draft for voting - Documento preparado pelo grupo de estudos para ser avaliado pela comissão) sem acordo entre a ISO e IEC, a principal disputa estava em definir quais requisitos do sistema da qualidade requerem Gerenciamento de Risco.
Com o passar do tempo outros pontos também não encontram consenso:
▫Classificação de segurança ( com base em lesão)
▫SW legado
▫Falta de provisões para novas tecnologias ( ex. IA)
O grupo recomendou que o projeto 62304 Edição 2.0 deve ter uma especificação de design com base em requisitos específicos, além de:
▫IEC 62304 é uma norma de segurança de software amplamente utilizada e reconhecido no setor de dispositivos médicos. A norma é usada por desenvolvedores, fabricantes e órgãos reguladores.
▫IEC 62304 é uma referência normativa em várias normas de dispositivos médicos (por exemplo, IEC 60601-1, ISO 14708-1, IEC 82304-1). Mudanças na norma não devem entrar em conflito com as necessidades dessas normas de produtos.
▫IEC 62304 Edição 1.0 é uma norma harmonizado MDD / AIMDD (UE), e a Edição 1.1 é reconhecida pelo FDA dos EUA. As mudanças na norma precisam continuar a se adequar às necessidades dos reguladores para o desenvolvimento de software seguro e eficaz.
2) A extensão do escopo para incluir software de saúde foi problemática para chegar a um consenso sobre a norma. O escopo da norma deve ser deixado para IEC / SC62A, ISO / TC215 (e ISO / TC210) e os comitês nacionais decidirem sobre a necessidade de normalização para processos de ciclo de vida de software de saúde.
A expansão do escopo para software de saúde foi um ponto central para chegar a um consenso na 2ª edição da 62304 devido aos diferentes interesses das partes envolvidas. Um conjunto de partes interessadas queria a norma para dispositivos médicos e uso regulatório, tornando o desafio de ser imparcial sobre o regulatório para software de saúde. Também continua a haver uma discussão de que o software de dispositivo médico é regulamentado de forma diferente nas jurisdições - o que é software de dispositivo médico em uma jurisdição não está em outra jurisdição.
A questão é se este é um problema a ser resolvido pela norma? Ou cabe ao fabricante escolher as normas a serem usadas?
Se este for um problema a ser resolvido pela norma, o grupo recomenda não diluir os requisitos da IEC 62304 para incluir software de saúde sob o risco de ed2 não ser reconhecido pelo FDA ou harmonizada na UE.
Outro ponto a estar ciente é que restringir o escopo do IEC 62304 para software de dispositivo médico pode causar problemas para chamar a norma IEC 82304-1 (que cobre SaMD e produtos de software de saúde não médicos). Isso também deixará uma lacuna na arquitetura de normas da ISO / TC215 para processos de desenvolvimento /manutenção de software de saúde.
IEC 82304-1: PRODUTOS DE SOFTWARE DE SAÚDE destina-se ao FABRICANTE para gerenciar, manter ou melhorar a saúde de pessoas individuais ou a prestação de cuidados. SOFTWARE DE SAÚDE refere-se a software que contribui para a saúde de pessoas individuais conforme observado e / ou demonstrado usando parâmetros de saúde mensuráveis ou experiência clínica.
*software as a medical device (SaMD) - SaMD é um software que executa uma ou mais funções médicas. Embora o software possa estar embutido em uma peça de hardware (como costuma ser o caso), é o próprio software que executa a função médica
A experiência da equipe do projeto da 2ª Edição 62304 mostra que o projeto durou muito (6 anos). Ao longo desse tempo, alguns fundamentos iniciais mudou 180 graus devido ao ambiente regulatório e ocorreu um “aumento de escopo” para adicionar novos requisitos para o estado da arte. Isso contribuiu para a dificuldade de se chegar a um consenso entre as partes interessadas da ISO e da IEC.
Há uma tendência da indústria para a terceirização de software desenvolvimento, mesmo para desenvolvedores não especializados no setor de dispositivos médicos. A terceirização de software poderia ser melhor apoiada ao aumentar a clareza da norma nas seguintes áreas:
- a) A interface do processo entre os processos no nível do fabricante do produto e os processos de desenvolvimento de software
- b) O cumprimento dos níveis de rigor do processo por meio do desenvolvimento de software terceirizado com base na avaliação de risco pelo fabricante do produto
- c) Um equilíbrio entre os resultados do processo prescrito necessários para o fabricante com a necessidade do fornecedor do software de proteger sua propriedade intelectual
- d) Os critérios usados pelo fabricante para avaliar um candidato para terceirização de desenvolvimento de software e sua conformidade com a norma
Por exemplo, como e com qual algoritmo AI deve ser treinado. A norma não deve incluir requisitos detalhados sobre como treinar uma rede. Ainda assim, deve exigir que esse treinamento seja documentado como parte de qualquer outra documentação de design que permita a repetibilidade da construção do software.
O grupo acha que a norma deve ser imparcial quanto à escolha do modelo de desenvolvimento.
Fornecer anexos informativos sobre o uso de requisitos 62304 com diferentes modelos de desenvolvimento seria útil para usuários e avaliadores. Também poderia ser considerado o desenvolvimento de uma “Orientação para a aplicação da IEC 62304”, uma vez que a ISO / TR24971 foi desenvolvida para a norma de gerenciamento de risco ISO 14971.
O padrão atual tem muitos exemplos de SiMD, mas um conjunto de exemplos mais diversificado deve ser considerado, incluindo computação em nuvem.
A sigla SIMD (Single Instruction, Multiple Data), descreve um método de operação de computadores com várias unidades operacionais em computação paralela. Neste modo, a mesma instrução é aplicada simultaneamente a diversos dados para produzir mais resultados.
Uma alternativa poderia ser definir interfaces de processo / fluxo de informações, como:
- ▫Requisitos de sistema / produto e fluxo de informações de arquitetura entre os processos de sistema e software
- ▫Alocação de gerenciamento de risco (fluxo de informações de gerenciamento de risco entre os processos de sistema e software (situações perigosas e risco associado)
Isso permitirá que os avaliadores (avaliação de terceiros ou fabricante do fornecedor / fornecedor) avaliem a conformidade com a norma mais facilmente. Uma alternativa seria estender um anexo que explica como a conformidade pode ser alcançada.
- Isso será útil para a avaliação do esquema IECEE CB quando incluído no teste / avaliação IEC 60601-1.
- Os organismos certificadores verificam a conformidade dos fabricantes com a norma. Isso permitirá uma verificação mais fácil de que os requisitos da norma são atendidos pela empresa
Recebemos comentários de que este caso deve ser considerado e que o software legado não deve ser considerado.
O grupo recomenda que a norma forneça um meio de conformidade sem exigir um redesenho completo do software.
Isso é para gerenciar software genérico que, devido a mudanças regulatórias, repentinamente se torna um software de saúde ou um crescimento funcional que muda o uso pretendido de um produto para se tornar um software de saúde.
O uso de itens de software, não desenvolvidos pelo fabricante, é uma prática comum para muitos desenvolvedores.
O grupo recomenda que a norma defina os requisitos sobre o uso seguro do que é comumente conhecido como SOUP ou OTS.
* Off-the-Shelf (OTS)- Componentes de software pré-desenvolvidos, geralmente desenvolvidos por outra organização e projetados para soluções específicas
- Software Of Unknown Provenance (SOUP)- Software de proveniência desconhecida geralmente entendidos como itens de software 'de prateleira' que são usados em um dispositivo médico
Há pelo menos dois aspectos aqui.
▫ A forma como os níveis de rigor do processo são determinados, mas também se é necessário.
▫Uma remoção completa da abordagem de rigor do processo provavelmente resultará em uma norma com o mais alto rigor de processo (Classe C) para satisfazer os requisitos regulamentares.
▫ No entanto, para permitir uma expansão de escopo, nós, como um grupo, achamos lógico esperar outro rigor de processo para um aplicativo inofensivo em comparação com um sistema de software de controle de suporte à vida.
Existem vários métodos possíveis para a determinação da classificação do software que podem ser investigados posteriormente.
▫A classificação de hoje é baseada em lesões, e o grupo sugere que, em vez disso, baseie a classificação em danos. Essa mudança se alinharia melhor com a ISO 14971 e incluiria melhor os aspectos de segurança do que é possível hoje.
▫Também é sugerido adotar as modificações do 62304 CDV3 no fluxograma para remover a “rota escape” para o nível A.
▫O grupo recomenda adotar a mudança proposta 62304 CDV3 para os níveis de rigor do processo (versus classificação de segurança de software).
▫Houve uma opinião de que a determinação do nível de rigor do software deve ser feita chamando as normas (ou seja, fora do 62304) porque tal decisão deve ser feita por atividades de gerenciamento de risco em nível de produto / sistema. Este método precisaria de coordenação adicional com as normas chamadas e o comitê de normas de desenvolvimento.
▫62304 CDV3 também incluiu um anexo informativo da categorização de risco SaMD e como os níveis de rigor do processo 62304 podem se alinhar. O grupo recomenda a adoção dessas informações em uma nova 2ª edição.
Como um grupo, recomendamos adotar a adição de descomissionamento que foi incluída no 62304 CDV3.
Outras melhorias podem incluir a seleção e manutenção do uso apropriado de itens de SOUP ou gerenciamento de atualizações e relançamentos do sistema de software.