O Blog Kolabtree

 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: 

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.

 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. 

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 -  

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:

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: 

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: 

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.


Kolabtree helps businesses worldwide hire freelance scientists and industry experts on demand. Our freelancers have helped companies publish research papers, develop products, analyze data, and more. It only takes a minute to tell us what you need done and get quotes from experts for free.


Unlock Corporate Benefits

• Secure Payment Assistance
• Onboarding Support
• Dedicated Account Manager

Sign up with your professional email to avail special advances offered against purchase orders, seamless multi-channel payments, and extended support for agreements.


Sair da versão mobile