O QUE DIA A RESOLUÇÃO

“4.1. Controle de Projeto

4.1.1. Instruções Gerais. Cada fabricante deverá estabelecer e manter procedimentos de controle do projeto do produto a fim de assegurar que os requisitos especificados para o projeto sejam obedecidos.

4.1.2. Planejamento de projeto e desenvolvimento. Cada fabricante deverá estabelecer e manter planos que descrevam ou referenciem as atividades de projeto e desenvolvimento e as pessoas responsáveis por cada atividade. Os planos deverão descrever ou fazer referência às atividades de desenvolvimento de projeto, inclusive qualquer interação entre os diversos grupos organizacionais e técnicos que possam ter alguma interface com o mesmo. Os planos deverão ser avaliados, atualizados e aprovados à medida que o desenvolvimento do projeto progrida”.erp

QUAL O ENTENDIMENTO

O requisito 4.1.1 estabelece a necessidade da existência de um procedimento de controle de projetos. Já o 4.1.2 vem mencionar a necessidade de previsão no procedimento da etapa de planejamento. É comum utilizar-se um termo de abertura de projetos (ou termo equivalente) nesta etapa. Este termo consiste em planejar e documentar:

  • Nome e código do projeto
  • Os envolvidos com o projeto (equipe, gerente do projeto etc.).
  • Os objetivos gerais do projeto
  • As premissas para o projeto.
  • O prazo previsto.
  • Os custos / orçamento associados.
  • Os riscos e os seus impactos envolvidos com o projeto.

Este registro será o primeiro (registro) que comporá o registro histórico do projeto.

O QUE DIZ A RESOLUÇÃO

kit“4.1.3. Dados de entrada de projeto. Cada fabricante deverá estabelecer e manter procedimentos para garantir que os requisitos relacionados a um produto estejam apropriados e atendam a sua intenção de uso, incluindo as necessidades do usuário e paciente e requisitos legais e regulamentares aplicáveis. Os procedimentos devem incluir um mecanismo que permita que requisitos incompletos, ambíguos ou conflituosos sejam identificados e tratados. Os dados de entrada de um projeto deverão ser documentados, avaliados e aprovados por uma pessoa designada qualificada. A aprovação dos requisitos, inclusive a data e a assinatura manual ou eletrônica do responsável pela aprovação, deverão ser documentados”.

QUAL O ENTENDIMENTO

A RDC 16/2013 define dados de entrada de projeto como sendo a “descrição dos atributos físicos, indicação de uso, desempenho, compatibilidade, segurança, eficácia, ergonomia, usabilidade, informações provenientes de projetos anteriores e resultados do gerenciamento de risco, dentre outros requisitos de um produto médico ou produto para diagnóstico de uso in vitro que são utilizados como base de seu projeto”. Basicamente, podemos concluir que são as informações e materiais referenciais que serão utilizados no decorrer do projeto.

Existem diversas formas de evidenciar o estabelecimento dos dados de entrada. Algumas empresas registram já no documento de planejamento e outras optam por um documento a parte, gerado pela equipe designada pelo projeto, após o inicio efetivo das atividades. Independente da forma escolhida é importante que esse documento seja aprovado pelos envolvidos designados para tal atividade com registro de data. A aprovação, conforme mencionado na resolução pode ser, inclusive eletrônica.

O QUE DIA A RESOLUÇÃO

“4.1.4. Verificação de projeto. Cada fabricante deverá estabelecer e manter procedimentos para a verificação do projeto do produto. A verificação de projeto deverá ser executada por pessoal designado e deverá assegurar que os dados de saída do projeto satisfaçam aos dados de entrada. Os resultados da verificação de projeto, incluindo a identificação do projeto verificado, métodos de verificação, data e nome da pessoa encarregada da verificação, deverão ser documentados no registro histórico do projeto.

4.1.5. Dados de saída de projeto. Cada fabricante deverá definir e documentar os dados de saída de projeto de maneira a permitir a avaliação da conformidade do projeto aos requisitos estabelecidos como dados de entrada. Os dados de saída do projeto deverão satisfazer os requisitos dos dados de entrada e deverão incluir os critérios de aceitação e identificar as características de projeto que são essenciais para o uso pretendido do produto. Estes deverão ser documentados, revisados e aprovados antes de sua liberação.

4.1.6. Revisão de Projeto. Cada fabricante deverá estabelecer e manter procedimentos para garantir que as avaliações dos resultados dos projetos sejam planejadas, conduzidas e documentadas nas diversas etapas do desenvolvimento do projeto. Os procedimentos deverão garantir que representantes de todas as funções diretamente relacionadas a etapa do projeto que esteja sendo revisada, assim como indivíduos de áreas relacionadas e especialistas necessários estejam envolvidos. Os resultados da revisão de projeto deverão ser documentados no registro histórico do projeto”.2 dias de auditoria

QUAL O ENTENDIMENTO

Neste caso, deve-se verificar, após a obtenção dos dados de saída, se os resultados estão atendendo aos dispositivos definidos no planejamento do projeto e estabelecidos nos dados de entrada. Dados de saída são os resultados do trabalho em cada fase do projeto e também seu resultado final. O dado de saída de projeto finalizado é a base para o registro mestre do produto (RMP). Observe que, em todas as etapas do projeto e à medida que o mesmo progride, será necessária a realização de atividades de revisões para obtenção de dados intermediários de saída. Em resumo, podemos dizer que a verificação consiste na comparação dos dados de saída obtidos com os dados de entrada estabelecidos e com os resultados planejados. Já a revisão do projeto vai acontecendo à medida que o projeto acontece, nas fases intermediárias.

O QUE DIZ A RESOLUÇÃO

“4.1.7. Transferência de projeto. Cada fabricante deverá estabelecer e manter procedimentos para assegurar que o projeto do produto esteja corretamente traduzido em especificações de produção.

4.1.8. Validação de projeto. Cada fabricante deverá estabelecer e manter procedimento para validar o projeto do produto. A validação do projeto deve ser realizada sob condições operacionais pré-determinadas, na produção inicial de lotes ou unidade. A validação de projeto deve garantir que o produto atenda às necessidades do usuário e indicação de uso e deverá incluir ensaios dos produtos em condições reais ou simuladas de uso. A validação de projeto deve incluir a validação de software, quando apropriado. Os resultados da validação de projeto, incluindo sua identificação, métodos, data e assinatura manual ou eletrônica dos responsáveis deverão ser documentados no registro histórico do projeto. Deverão ser realizados estudos de estabilidade sempre que aplicável.

4.1.9. Liberação de projeto. Cada fabricante deverá assegurar que o projeto não seja liberado para a produção até que esteja aprovado pelas pessoas designadas para tal pelo fabricante. As pessoas designadas deverão revisar todos os registros exigidos para o registro histórico do projeto, a fim de assegurar que este esteja completo e que o projeto final esteja compatível com os planos aprovados, antes de sua liberação. Esta liberação, incluindo data e assinatura manual ou eletrônica do responsável, deverá ser documentada.”

QUAL O ENTENDIMENTO

A transferência, validação e liberação são três conceitos interligados. A transferência é a tradução do projeto do produto em especificação. Geralmente, após a tradução, faz-se o piloto (ou os lotes pilotos) para verificar se o processo está correto, bem como para verificar se o produto final está atendendo as expectativas. Costumo dizer que, nesta fase, o produto sai do laboratório para fabricação do piloto. Com o piloto e o registro de sua produção (que é o registro histórico do produto do(s) piloto(s)), faz a validação do projeto. Nesta validação, realiza-se simulação e ensaios e outras atividades de modo a garantir que o produto é seguro (não cause dano) e eficaz (funciona corretamente). Somente após a validação é que se vai fazer a transferência que é, justamente, a transferência do produto para a produção efetivamente. O registros dessas etapas comporão o registro histórico do projeto.

O QUE DIZ A RESOLUÇÃO

“4.1.10. Alterações de projeto. Cada fabricante deverá estabelecer e manter procedimentos para a identificação, documentação, validação, revisão e aprovação das alterações de projeto antes de sua implementação, incluindo uma avaliação dos riscos dentro do processo de gerenciamento de riscos.

4.1.11. Registro histórico de projeto. Cada fabricante deverá estabelecer e manter um registro histórico de projeto para cada produto. O registro histórico de projeto deverá conter ou fazer referência a todos os registros necessários para demonstrar que o projeto foi desenvolvido de acordo com o plano de projeto aprovado e os requisitos deste Regulamento Técnico”.

QUAL O ENTENDIMENTO

kitPrimeiramente, no item 4.1.10, temos a obrigatoriedade de documentação de qualquer alteração que o projeto venha a sofrer no decorrer de sua execução. As alterações podem ser regulamentares (por normas e leis, por exemplo), a pedido de um cliente ou por outros motivos. Esses registros de alterações também farão parte do registro histórico do projeto. Já o requisito 4.1.11 diz respeito ao registro histórico do projeto. Trata-se do compêndio de registros gerados ao longo da execução do projeto, desde o planejamento, até a liberação. Deve estar vinculado a cada projeto e será a base para a elaboração do RMP. Quando se coloca que será a base, significa que as informações e resultados positivos obtidos no projeto (dados de saída), serão convertidos no RMP. Isso porque um projeto tem resultados que deram certo e resultados que deram errado.

Vá para o capítulo 4.2 – Clique AQUI

Volte para o capítulo 4 – Clique AQUI

Forte abraço do consultor e autor deste material, Rodrigo Sousa.

OBS: este material está registrado na Biblioteca Nacional e é protegido pelos direitos autorais. Vedado uso para fins comercias. Deve sempre citar a fonte. Seja ético!

Gosta do nosso blog? Quer nos ajudar? Conheça e adquira os produtos voltados para a RDC 16/2013 na Loja da Qualidade ou simplesmente faça um comentário nesta postagem.


Warning: include_once(sidebar-bg.gif): failed to open stream: No such file or directory in /home4/qnp/public_html/wp-content/themes/qnp/footer.php on line 1

Warning: include_once(): Failed opening 'sidebar-bg.gif' for inclusion (include_path='.:/opt/php54/lib/php') in /home4/qnp/public_html/wp-content/themes/qnp/footer.php on line 1