Documentação de software do FDA para dispositivos médicos

Freelance redator regulamentar Shreya Chenni fornece um guia para a documentação de software da FDA para dispositivos médicos, incluindo uma quebra dos requisitos com base na classificação. 

O dispositivo médico industry is seeing rapid technological advancement and a high rate of innovation.  Nowadays, many devices are AI-enabled, which allows early detection of disease, identification of different patterns of a biological activity, and improved diagnostic accuracy. Some examples of AI-enabled applications or devices include Arterys Application, Philips WSI and QuantX by Quantitative Insights. The software has to be verified and validated, to ensure its safety and effectiveness. 

Para qualquer dispositivo que contenha software que passe pelo rota 510(k)Os documentos específicos relacionados a software têm que ser apresentados. Neste artigo, discutimos os documentos necessários para 510(k) submissões e entender como esboçá-los com base na classificação de seu software.  

Como classificar seu software de dispositivo médico? 

Identificar o Nível de Preocupação aplicável (LoC). Há três níveis: 

• Maior: uma falha ou falha latente pode resultar diretamente em morte ou ferimento grave do paciente ou operador 

OU 

 uma falha ou falha latente pode resultar indiretamente na morte ou ferimento grave do paciente ou operador através de informações incorretas ou atrasadas ou através da ação de um prestador de cuidados.

• Moderado: uma falha ou falha de projeto latente pode resultar diretamente em lesões menores ao paciente ou ao operador

 OU 

uma falha ou falha latente pode resultar indiretamente em lesões menores ao paciente ou ao operador através de informações incorretas ou atrasadas ou através da ação de um prestador de cuidados. 

• Menor: se falhas ou falhas de projeto latentes são improváveis de causar qualquer dano ao paciente ou ao operador. 

Use a Tabela 1 e a Tabela 2 do Orientação da FDA para o Conteúdo de Envios Pré-mercados de Software Contido em Dispositivos Médicos para responder às perguntas e determinar seu Nível de Preocupação com o Software. 

Documentos de software do FDA para dispositivos médicos

Quais são os documentos a serem apresentados?

Softwares de nível moderado e de grande preocupação têm 11 documentos diferentes a serem apresentados. Já os softwares de menor nível de preocupação requerem sete documentos diferentes. O escopo e a extensão dos detalhes nesses documentos varia com base em seu LoC.

A tabela a seguir identifica os documentos necessários para cada um dos níveis de preocupação: 

Menor	Moderado	Major
Nível de preocupação	Nível de preocupação	Nível de preocupação
Descrição do software	Descrição do software	Descrição do software
Análise de risco do dispositivo	Análise de risco do dispositivo	Análise de risco do dispositivo
Especificação de requisitos de software (SRS)	Especificação de requisitos de software (SRS)	Especificação de requisitos de software (SRS)
Análise de Rastreabilidade	Análise de Rastreabilidade	Análise de Rastreabilidade
Documentação de Verificação e Validação	Documentação de Verificação e Validação	Documentação de Verificação e Validação
Histórico do nível de revisão	Histórico do nível de revisão	Histórico do nível de revisão
————	Gráfico de projeto de arquitetura	Gráfico de projeto de arquitetura
————	Documento de especificação de projeto de software	Documento de especificação de projeto de software
————	Software Development Environment Description	Descrição do Ambiente de Desenvolvimento de Software
————	Anomalias não resolvidas (Bugs ou Defeitos)	Anomalias não resolvidas (Bugs ou Defeitos)

 

Descrição dos documentos 

1. Nível de preocupação 

Registrar as respostas às perguntas da Tabela 1 e da Tabela 2 do Orientação da FDA para o Conteúdo de Envios Pré-mercados de Software Contido em Dispositivos Médicos  neste documento. Incluir uma fundamentação para o determinado nível de preocupação. 

2. Descrição do software

Este documento apresenta o software do dispositivo e, portanto, deve fornecer uma visão abrangente das características, funcionalidades, uso pretendido. Incluir linguagem de programação, plataforma de hardware, sistema operacional e uso de software Off-the-Shelf conforme aplicável. Figuras e diagramas devem ser incluídos conforme apropriado. 

Caso o dispositivo utilize software Off-the-Shelf, consulte o documento de orientação da FDA".Orientação para o uso de software fora da prateleira em dispositivos médicos.” 

3. Análise de risco do dispositivo 

 A device hazard analysis is a must. All the foreseeable hazards associated with the intended use of the device (software and hardware) should be captured. The risk analysis should be conducted in compliance with ISO 14971. The hazard analysis should identify the hazard, hazardous, severity of the hazard, cause of the hazard, risk control measure and verification of the control measure. 

4. Especificação dos requisitos de software

A Especificação de Requisitos do Software (SRS) documenta todos os requisitos para o software. Basicamente, os requisitos descrevem o que o software deve fazer. Os requisitos podem ser colocados em diferentes baldes, tais como funcionais, de desempenho, de interface de usuário e regulamentares. 

Para LoC menores, o SRS pode ser um resumo dos requisitos funcionais, porém, para os moderados e maiores, os requisitos têm de ser detalhados e tipicamente listados. Certifique-se de que cada requisito listado tenha um ID de requisito atribuído a ele, como SRS-01, SRS-02 e assim por diante. 

Aqui estão alguns exemplos da SRS: 

Requisitos de hardware: Incluir os requisitos sobre -  

• microprocessadores 
• dispositivos de memória
• sensores 
• fontes de energia 
• características de segurança
• comunicações

Requisitos de programação: Incluir os requisitos de tamanho do programa, restrições, etc. 

Requisitos de interface: Incluir requisitos que descrevem a comunicação entre o software e os dispositivos de hardware, tais como impressoras, monitores. Outros requisitos, como o sistema operacional com o qual o software é compatível e assim por diante. 

Software Performance and Functional Requirements Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. 

O desempenho do software e os requisitos funcionais também podem incluir:

• Limitações do dispositivo devido ao software 
• Testes e verificações internas de software
• Tratamento de erros e interrupções 
• Características de detecção de falhas, tolerância e recuperação 12 Contém recomendações não vinculativas 
• Exigências de segurança
• Requisitos de tempo e memória 
• Identificação de software pronto para uso, se apropriado. 

5. Gráfico de projeto de arquitetura

 Este documento apresenta claramente a relação, fluxo de dados e interação entre os principais componentes ou blocos funcionais do software. Isto é normalmente retratado na forma de fluxograma, diagramas de blocos e outras formas, conforme apropriado. Para software de nível moderado e de maior preocupação, o diagrama de projeto pode incluir diagramas de estado. 

6. Especificações de projeto de software (SDS)

A implementação dos requisitos está detalhada neste documento. Cada SDS deve ser numerado, tal como o SDS-01, semelhante ao SRS. Cada exigência incluída na SRS deve ter uma especificação de projeto correspondente. Entretanto, também é possível que uma única especificação de projeto possa corresponder a um grupo de requisitos. 

7. Análise de Rastreabilidade

Este documento vincula os requisitos, especificações de projeto, perigos e testes de V&V. A matriz de rastreabilidade pode ser elaborada conforme abaixo, detalhes podem ser acrescentados conforme apropriado: 

Necessidade do usuário (opcional)	SRS	SDS	Perigos	Casos de teste V&V
UND-001	SRS-001 SRS-002	SDS-001	Haz-001	TC-001
UND-002	SRS-002	SDS-001 SDS-002	Haz-002	TC-002 TC-004

 

8. Descrição do ambiente de desenvolvimento de software (SDED)

É necessário um software moderado e de alto nível de preocupação para apresentar um SDED que descreva o plano do ciclo de vida de desenvolvimento de software, manutenção e atividades de software. O nível de detalhamento difere para Moderado e Major. Consulte a EN 62304 Tabela 1: Tabela A.1 - Resumo dos requisitos por classe de segurança de software. Isto pode ser usado para identificar os elementos a serem incluídos e as atividades que devem ser documentadas por sua classe. As três classes A, B e C estão alinhadas com o nível de preocupação da FDA.  

9. Documentação de Verificação e Validação

LoC Menor: Teste de nível do dispositivo de documento e teste de integração (se aplicável). Assegurar que os casos de teste tenham um critério de aceitação e um resumo dos resultados do teste. 

LoC moderado: Lista resumida de documentos de validação e verificação de atividades e seus resultados. Incluir critérios de aceitação. Garantir que a Análise de Rastreabilidade faça referência a IDs de casos de teste. 

Major LoC: Além das informações acima (LoC Moderado), a descrição de quaisquer testes fracassados e as mudanças feitas em resposta a eles devem ser documentadas. 

10. Histórico do nível de revisão

Documentar as principais mudanças no software, assegurando que a última linha tempo/entrada seja a última versão do software. Identificar o número da versão, data e descrever as mudanças em relação à versão anterior. 

11. Anomalias não resolvidas 

Documentar os bugs não resolvidos existentes no software que está sendo lançado. Capture o seguinte para cada bug: 

• O problema
• Impacto no desempenho do dispositivo 
• Cronogramas planejados para corrigir estes erros (se aplicável) 

The above eleven documents cover the entire documentation necessary for the device software. Additionally, FDA requires Ciber-segurança Documentation such as cybersecurity plan, risk management and V&V tests and their results. For more information on this FDA guidelines on Cybersecurity requirements refer to: Conteúdo das Submissões Premarket para Gerenciamento de Segurança Cibernética em Dispositivos Médicos. 

Referências: 

• Orientação para o Conteúdo de Envios Pré-mercados de Software Contido em Dispositivos Médicos

Precisa de ajuda com a documentação do software da FDA para dispositivos médicos? Entre em contato com os redatores freelance de regulamentação e Especialistas em apresentação da FDA em Kolabtree.