GUIA PARA CONTROLE DE PROJETOS PARA FABRICANTES DE DISPOSITIVOS MÉDICOS

Resolução RDC nº 16/2013, requisito 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 documentadas.

Entradas de projeto são o ponto de partida para o efetivo desenvolvimento de um dispositivo médico. Os dados que formam as entradas de projeto estabelecem uma base para executar tarefas de projeto subsequentes. Portanto, o desenvolvimento de uma base sólida de requisitos é, assim, a atividade de controle de projeto mais importante.

Muitos fabricantes de dispositivos médicos têm experiência com os sucessivos problemas no processo de desenvolvimento de projetos ocasionados por dados incompletos estabelecidos no início. Se os requisitos essenciais não forem adequadamente identificados, redesenho e retrabalho caros podem ser necessários antes que um projeto possa ser liberado para a produção.

Por outro lado, fabricantes que projetam dispositivos usando conjuntos de requisitos claros e abrangentes tendem a obter significante redução em retrabalho e redesenho, além de resultar em aprimoramento da qualidade dos produtos. É conhecido que o desenvolvimento de requisitos para um dispositivo médico é uma tarefa desafiadora e demorada, em particular nos casos de complexidade ou risco médios ou altos. Entretanto, faz-se necessário o investimento em tempo e recursos exigidos para desenvolver adequadamente os requisitos, que inclusive resultem em vantagens relacionadas à segurança, eficácia e qualidade e mesmo de otimização de processos produtivos que serão observadas principalmente no médio e longo prazo.

Infelizmente, há uma série de equívocos comuns sobre o significado e a aplicação prática dos requisitos do sistema da qualidade para entrada de projeto. Muitos parecem surgir da interpretação dos requisitos como uma prescrição literal, ao invés de um conjunto de princípios a serem seguidos. Neste documento de orientação, o foco é explicar os princípios e ilustrar com exemplos de como eles podem ser aplicados em situações típicas.

DOCUMENTOS DE CONCEITO VERSUS ENTRADA DE PROJETO. Em alguns casos, a equipe de marketing, que mantém contato próximo com clientes e usuários, determina a necessidade de um novo produto ou de aprimoramentos em um produto existente. Alternativamente, a ideia de um novo produto pode evoluir de uma pesquisa ou atividade clínica. Em qualquer caso, o resultado é um documento conceitual especificando algumas das características desejadas do novo produto.

Alguns membros da comunidade de dispositivos médicos veem esses memorandos de marketing ou equivalentes, como uma entrada de projeto. No entanto, essa não é a intenção dos requisitos em um sistema da qualidade. Esses documentos conceituais raramente são abrangentes e não se espera que o sejam. Em vez disso, a intenção dos requisitos em sistemas da qualidade, neste contexto é que a descrição conceitual do produto seja elaborada, expandida e transformada em um conjunto completo de requisitos de entrada de projeto que são escritos em um nível de detalhe de engenharia.

Esse é um conceito importante. O uso de termos qualitativos em um documento conceitual é apropriado e prático, entretanto, frequentemente, esse não é o caso de um documento a ser usado como base para o desenvolvimento. Mesmo os termos mais simples utilizados em documentos conceituais podem ter enormes implicações no projeto que devem ser traduzidas justamente pelas entradas de projeto, i.e., pelo estabelecimento dos requisitos físicos e de desempenho que serão usados como base para o desenvolvimento do dispositivo médico.

Por exemplo, o termo “deve ser portátil” em um documento conceitual levanta questões nas mentes dos desenvolvedores de produtos sobre questões como limitações de tamanho e peso, resistência a choques e vibrações, a necessidade de proteção contra umidade e corrosão, a capacidade de operação em uma ampla faixa de temperatura e muitos outros. Dessa forma, um documento de conceito pode ser o ponto de partida para o desenvolvimento, mas não é o requisito de entrada do projeto. Este é um princípio fundamental – os requisitos de entrada do projeto são o resultado da primeira etapa do processo de controle e desenvolvimento do projeto.

PESQUISA E DESENVOLVIMENTO. Alguns fabricantes têm dificuldade em determinar onde termina a pesquisa e começa o desenvolvimento. As atividades de pesquisa podem ser realizadas em um esforço para determinar novas oportunidades de negócios ou características básicas para um novo produto. Pode ser razoável desenvolver um protótipo rápido para explorar a viabilidade de uma ideia ou abordagem de projeto, por exemplo, antes de desenvolver os requisitos de entrada do projeto. Mas os fabricantes devem evitar cair na armadilha de igualar o projeto do protótipo ao projeto do produto acabado. Os protótipos neste estágio carecem de recursos de segurança e funções auxiliares necessárias para um produto acabado e são desenvolvidos sob condições que impedem a consideração adequada da variabilidade do produto ocasionada pela fabricação.

RESPONSABILIDADE PELO DESENVOLVIMENTO DOS DADOS DE ENTRADAS DE PROJETO. Independentemente de quem desenvolveu o conceito inicial do produto, os desenvolvedores do produto desempenham um papel fundamental no desenvolvimento dos requisitos de entrada de projeto. Quando apresentado a um conjunto de características importantes, são os desenvolvedores de produto que entendem as questões auxiliares que devem ser tratadas, bem como o nível de detalhe necessário para projetar um produto. Portanto, um segundo princípio fundamental é que o(s) desenvolvedor(es) do produto, em última análise, sejam responsáveis por traduzir as necessidades do usuário e/ou do paciente em um conjunto de requisitos que podem ser validados antes da implementação. Embora esta seja principalmente uma função de engenharia, o suporte ou a participação total do pessoal de produção e serviço, fornecedores-chave, entre outros, pode ser necessário para garantir que os requisitos de entrada do projeto sejam completos.

Deve-se ter cuidado ao aplicar este princípio. O desenvolvimento eficaz dos requisitos de entrada de projeto abrange a entrada tanto do desenvolvedor do produto quanto daquelas que representam as necessidades do usuário e marketing, inclusive. A terminologia pode ser um problema. Em alguns casos, a descrição conceitual do produto pode ser expressa em termos médicos. A terminologia médica é apropriada em requisitos quando os desenvolvedores e revisores estão familiarizados com a linguagem, mas geralmente é preferível traduzir os conceitos em termos de engenharia na fase de requisitos e dados de entrada para minimizar falhas de comunicação com a equipe de desenvolvimento.

Outro problema são as suposições incorretas. Os desenvolvedores de produtos fazem suposições incorretas sobre as necessidades do usuário e a equipe de marketing faz suposições incorretas sobre as necessidades dos desenvolvedores de produtos. Suposições incorretas podem ter consequências graves que podem não ser detectadas até o final do processo de desenvolvimento. Portanto, tanto os desenvolvedores de produtos quanto aqueles que representam o usuário devem assumir a responsabilidade por examinar criticamente os requisitos propostos, explorando suposições declaradas e implícitas, bem como descobrindo problemas e eventuais conflitos ou contradições entre requisitos.

Alguns exemplos podem esclarecer este ponto. Um princípio básico é que os requisitos de entrada do projeto devem especificar o que o projeto se destina a fazer, evitando cuidadosamente soluções de projeto específicas neste estágio. Por exemplo, um documento de conceito pode ditar que o produto seja alojado em uma caixa de alumínio usinado. Seria prudente para os desenvolvedores de produtos explorar o porquê da especificação desse tipo de caixa. Talvez haja um motivo válido – blindagem elétrica superior, resistência mecânica ou tempo reduzido de lançamento no mercado em comparação com uma carcaça fundida. Ou talvez o alumínio usinado tenha sido especificado porque o produto de um concorrente é feito dessa forma ou simplesmente porque o usuário não achou que o plástico seria forte o suficiente.

Nem todas as suposições incorretas são feitas pelos usuários. Suposições incorretas feitas por desenvolvedores de produtos podem ser igualmente prejudiciais. A falta de compreensão da violação a que um instrumento portátil estaria sujeito pode resultar na seleção de materiais de invólucro inadequados para o uso pretendido do produto.

Há ocasiões em que pode ser apropriado especificar parte da solução do projeto nos requisitos de entrada do projeto. Por exemplo, um fabricante pode querer compartilhar componentes ou processos de fabricação em uma família de produtos para obter economias de escala ou simplesmente para ajudar a estabelecer uma identidade corporativa. No caso de uma atualização de produto, pode haver um consenso claro sobre os recursos a serem mantidos. No entanto, é importante perceber que cada restrição de projeto reduz a flexibilidade de implementação e, portanto, deve ser documentada e identificada como um possível requisito conflitante para resolução subsequente.

ESCOPO E NÍVEL DE DETALHE. Os dados de entrada do projeto devem ser abrangentes. Isso pode ser muito difícil para os fabricantes que estão implementando um sistema de controles de projeto pela primeira vez, porém, felizmente, o processo fica mais fácil com a prática. Pode ser útil perceber que os requisitos de entrada do projeto se enquadram em três categorias. Praticamente todos os dispositivos médicos terão requisitos de três tipos, conforme se segue.

1. Os requisitos funcionais especificam o que o dispositivo faz, concentrando-se nas capacidades operacionais do dispositivo e no processamento de entradas e saídas resultantes
2. Os requisitos de desempenho especificam quanto ou quão bem o dispositivo deve funcionar, abordando questões como velocidade, força, tempos de resposta, precisão, limites de operação, entre outros. Isso inclui uma caracterização quantitativa do ambiente de uso, incluindo, por exemplo, temperatura, umidade, choque, vibração e compatibilidade eletromagnética. Os requisitos relativos à confiabilidade e segurança do dispositivo também se enquadram nesta categoria.
3. Os requisitos de interface especificam as características do dispositivo que são críticas para a compatibilidade com sistemas externos, especificamente, aquelas características que são exigidas por sistemas externos e fora do controle dos desenvolvedores. Uma interface importante em todos os casos é a interface do usuário e/ou paciente.

Então, qual seria o escopo do processo de desenvolvimento de dados de entrada de projeto e quantos detalhes devem ser fornecidos? O escopo depende da complexidade do produto em desenvolvimento e do risco associado ao seu uso. Para a maioria dos dispositivos médicos, vários requisitos que abrangem funções, desempenho, segurança e questões regulatórias estão implícitos na aplicação. Esses requisitos implícitos devem ser declarados explicitamente, em termos de engenharia, nos dados de entrada do projeto.

Determinar o nível apropriado de detalhes requer experiência, entretanto, algumas orientações gerais são possíveis. A literatura de marketing pode conter especificações do produto, mas em termos de engenharia serão superficiais. Os manuais do operador e de serviço podem conter especificações mais detalhadas e limites de desempenho, mas também não são abrangentes.

Alguma reflexão acerca do que é necessário pode ser alcançada examinando os requisitos para uma interface externa muito comum, como ilustração. Por exemplo, para os requisitos de energia para equipamentos eletromédicos, não é suficiente simplesmente dizer que uma unidade deve ser alimentada por corrente alternada (AC). É melhor dizer que a unidade deve ser operada com corrente alternada, p.ex., em determinada região do país ou do mundo, mas isso ainda é detalhe insuficiente para implementar ou validar o projeto. Se considerarmos a situação apenas em uma região geográfica onde a tensão da linha é normalmente de 120 volts, muitos sistemas são especificados para operar na faixa de 108 a 132 volts. No entanto, para levar em conta a possibilidade de queda de energia, dispositivos críticos podem ser especificados para operar de 95 a 132 volts ou faixas ainda mais amplas. Com base na indicação de uso do dispositivo médico, o fabricante deve escolher os limites de desempenho apropriados.

Há muitos casos em que é impraticável estabelecer todas as características funcionais e de desempenho no estágio de entrada do projeto, porém, na maioria absoluta dos casos, a forma do requisito pode ser determinada e o requisito pode ser declarado com um valor numérico a ser definido ou uma faixa de valores possíveis. Isso possibilita que os revisores avaliem se os requisitos caracterizam completamente a indicação de uso do dispositivo, julgam o impacto das omissões e rastreiam os requisitos incompletos para garantir a adequada resolução.

Para projetos complexos, não é incomum que o estágio de estabelecimento de dados de entrada de projeto consuma até trinta por cento do tempo total do projeto. Infelizmente, alguns gerentes e desenvolvedores foram treinados para medir o progresso dos projetos em termos, por exemplo, de hardware construído ou linhas de código de software escritas. Eles não percebem que construir uma base sólida economiza tempo durante a implementação. Parte da solução é estruturar os documentos de requisitos e revisões de forma que medidas tangíveis de progresso sejam fornecidas.

No outro extremo, muitos dispositivos médicos têm requisitos muito simples. Por exemplo, muitos dispositivos novos são simplesmente peças de reposição de um produto, kits de itens de consumo de produtos já desenvolvidos ou novos acessórios para estes produtos. Em algumas situações, pode acontecer de apenas a embalagem e a rotulagem distinguir esses dispositivos novos dos produtos já existentes. Nesses casos, não há necessidade de recriar os requisitos de entrada do projeto detalhado do item. É aceitável simplesmente citar a documentação do produto anterior, adicionar qualquer nova informação do produto e estabelecer os requisitos exclusivos, nesse caso, de embalagem e rotulagem.

AVALIAÇÃO DOS DADOS DE ENTRADA DE PROJETO PARA ADEQUAÇÃO. Eventualmente, os dados de entrada de projeto devem ser revisados para adequação. Após a revisão e aprovação, os dados de entrada de projeto são incorporados a documento controlado. Todas as mudanças futuras estarão sujeitas aos procedimentos de controle de mudanças, conforme discutido na Seção 9.

Qualquer avaliação dos dados de entrada do projeto se resume a uma questão de julgamento. Conforme se discute na Seção 5 (Revisão do Projeto), é importante que a equipe de revisão seja multidisciplinar e tenha a autoridade apropriada. Vários critérios podem ser empregados pela equipe de revisão.

Os dados de entrada do projeto devem ser inequívocos. Ou seja, cada requisito deve possibilitar a sua verificação por um método objetivo de análise, inspeção ou teste. Por exemplo, é insuficiente afirmar que um cateter deve ser capaz de suportar flexões repetidas. Uma exigência melhor seria que o cateter deveria ser formado em uma bobina de 50 mm de diâmetro e endireitado por um total de cinquenta vezes, sem evidência de rachadura ou deformidade. Um revisor qualificado pode então fazer um julgamento se este método de teste especificado é representativo das condições de uso.

Os limites quantitativos devem ser expressos com uma tolerância de medição. Por exemplo, um diâmetro de 3,5 mm é uma especificação incompleta. Se o diâmetro for especificado como 3,500 ± 0,005 mm, os projetistas têm uma base para determinar a precisão dos processos de fabricação para produzir peças compatíveis e os revisores têm uma base para determinar se as peças serão adequadas para o uso pretendido. Nos casos em que as medidas de dimensões tenham especificações de alta precisão, pode ser necessário que seja determinada a faixa de temperatura a ser mantida no momento da medida, pois esta pode interferir tanto nas dimensões do produto quanto na precisão dos instrumentos de medida.

O conjunto de dados de entrada do projeto para um produto deve ser plenamente consistente. Não é incomum que os requisitos entrem em conflito uns com os outros ou com algum padrão da indústria ou mesmo regulatórios por consequência de simples descuidos. Esses conflitos, portanto, devem ser identificados e resolvidos no início do processo de desenvolvimento.

O ambiente no qual o produto se destina a ser usado deve ser devidamente caracterizado. Por exemplo, um fabricante pode cometer o erro de especificar condições de “laboratório” para dispositivos médicos destinados ao uso doméstico. No entanto, mesmo dentro de um único país, a umidade relativa em uma residência pode variar de 20% a 100% (condensação) devido às variações climáticas e sazonais. As temperaturas domésticas em muitos climas podem ultrapassar 40 ° C durante a estação quente. As altitudes podem variar substancialmente e a baixa pressão atmosférica resultante pode afetar adversamente alguns tipos de equipamentos médicos. Se as condições ambientais forem totalmente especificadas, um revisor qualificado pode determinar se as condições especificadas são representativas do uso pretendido.

Quando normas técnicas, códigos de referência ou padrões industriais são citados, as citações devem ser revisadas para integridade e relevância. Por exemplo, um fabricante de dispositivos médicos poderia reivindicar conformidade com norma técnica aplicada a testes de verificação de choque mecânico e vibração. No entanto, poderia acontecer que mediante exame de um revisor, fosse constatado que a norma técnica desse exemplo prescrevesse apenas o método de teste, omitindo qualquer menção aos critérios de aprovação/reprovação.

Nesse caso, caberia ao fabricante especificar os limites de desempenho apropriados para o dispositivo testado, além do método de teste.

EVOLUÇÃO DOS REQUISITOS DE ENTRADA DE PROJETO. Projetos extensos de dispositivos médicos complexos são geralmente implementados em estágios. Quando isso ocorre, os dados de entrada do projeto em cada estágio devem ser desenvolvidos e revisados seguindo os princípios estabelecidos nesta seção. Felizmente, o conjunto inicial de requisitos, cobrindo o produto geral, é, incomparavelmente, o mais difícil de desenvolver. À medida que o projeto avança, a saída dos estágios iniciais forma a base para os estágios subsequentes, e as informações disponíveis para os projetistas são inerentemente mais extensas e detalhadas.

É quase inevitável que as atividades de verificação revelem discrepâncias que resultem em mudanças nos dados de entrada do projeto. Há dois pontos a serem destacados sobre isso.

O primeiro é que o processo de controle de mudanças para os dados de entrada do projeto deve ser cuidadosamente gerenciado. Frequentemente, uma mudança de projeto para corrigir um problema pode criar um problema novo que deve ser tratado. Ao longo do processo de desenvolvimento é importante que quaisquer mudanças sejam documentadas e comunicadas aos desenvolvedores para que o impacto total da mudança possa ser determinado. O processo de controle de alterações é crucial para a qualidade do dispositivo.

O segundo ponto é que o retrabalho extensivo dos dados de entrada do projeto sugere que esses podem não ter sido elaborados em um nível adequado de detalhe, ou recursos insuficientes tenham sido dedicados à definição e revisão desses requisitos. Contudo, de uma perspectiva de controle de projeto, o número de mudanças de requisitos feitas é menos importante do que a profundidade do processo de controle de mudanças.