Na era actual de desenvolvimento ágil, DevOps e ciclos de iteração rápidos, muitos programadores vêem a IEC 62304 como um resquício de um tempo mais antigo. O seu ciclo de vida de software clássico e a sua dependência do modelo em V parecem muitas vezes contrários às práticas de desenvolvimento flexíveis e rápidas.

Mas a IEC 62304 nunca foi concebida para ser uma prescrição rígida de como o software deve ser construído. Em vez disso, oferece uma estrutura robusta para demonstrar o controlo, a segurança e a rastreabilidade - elementos fundamentais que são críticos, independentemente de a sua equipa trabalhar em sprints de duas semanas ou em ciclos de cascata mais longos.

Rastreabilidade: O Princípio Não-Negociável

No coração da IEC 62304 está o conceito de rastreabilidade. Isto inclui:
- Requisitos de software definidos e testáveis,
- Decisões de arquitetura e design documentadas,
- Actividades de verificação alinhadas e registadas,
- Medidas de controlo de risco integradas de acordo com a ISO 14971,
- Gestão de anomalias de software e alterações de configuração.
Estes princípios aplicam-se universalmente - quer a sua equipa utilize Scrum, Kanban ou qualquer estrutura ágil híbrida.

IEC 62304 e Ágil: Compatíveis por Design

Embora a IEC 62304 promova um ciclo de vida estruturado, ela é fundamentalmente agnóstica em termos de metodologia. O desenvolvimento ágil pode alinhar-se com as suas expectativas quando interpretado através da lente dos resultados e artefactos, em vez de uma sequência rígida.

Os sprints podem fornecer componentes testados de forma incremental; os backlogs podem ser mapeados para especificações de requisitos. A chave é que todas as actividades do ciclo de vida - desde os requisitos até à verificação - sejam documentadas, revistas e controladas.

O que importa não é a forma como constrói o seu software, mas a forma como consegue demonstrar que é seguro, eficaz e que cumpre as expectativas regulamentares.

Repensando o Modelo V como um andaime de documentação

O modelo V, frequentemente visto como sinónimo da norma IEC 62304, não deve ser considerado como um manual de instruções para processos de desenvolvimento. Em vez disso, é melhor entendido como um andaime de documentação - uma visualização do alinhamento entre as actividades de desenvolvimento e a sua verificação correspondente.
O desenvolvimento ágil encaixa-se neste modelo quando:

- Os requisitos são rastreados até aos casos de teste,

- As decisões de design são validadas,

- As alterações de código são controladas e revistas,

- Os lançamentos são documentados com as correspondentes avaliações de risco.

Alinhamento com as expectativas regulamentares

Os órgãos reguladores continuam a reconhecer e confiar na IEC 62304, não pela sua estrutura de ciclo de vida, mas pelas suas expectativas consistentes e auditáveis:

Os requisitos de alto nível, conforme indicado no Anexo II - Regulamento de Dispositivos Médicos (MDR 2017/745), podem ser rastreados até requisitos mais específicos de software indicados pela IEC 62304, como requisitos, gestão de riscos e controlo de configuração, histórico de versões de software e verificação baseada em riscos, que são naturalmente suportados pela estrutura da IEC 62304. Até mesmo o Guia de Orientação 2023 da FDA sobre documentação de software faz um mapeamento direto dos conceitos da IEC 62304.

O que os reguladores querem é a garantia de que os fabricantes compreendem o seu software, podem verificar o seu comportamento e podem mitigar os seus riscos. A IEC 62304 continua a ser a forma mais harmonizada globalmente para fornecer essa garantia.

Como Organismo Notificado no âmbito do MDR, a DQS-MED continua a reconhecer a IEC 62304 como a norma mais adequada para a documentação estruturada dos processos do ciclo de vida do software de dispositivos médicos.

Conclusão: A IEC 62304 é uma norma que merece ser reinterpretada

A IEC 62304 não é uma relíquia do passado - é uma âncora regulamentar para o desenvolvimento moderno de software.

Sim, a IEC 62304 precisa de ser reinterpretada, ou mesmo adaptada às realidades dos ambientes de desenvolvimento actuais. O seu modelo de ciclo de vida pode parecer tradicional, mas os seus princípios - rastreabilidade, verificação e controlo - são intemporais.

De facto, à medida que adoptamos estratégias de desenvolvimento mais ágeis e flexíveis, esses princípios tornam-se ainda mais críticos para os programadores de software para dispositivos médicos que pretendem garantir não só a conformidade, mas também a segurança dos doentes.

Software em conformidade começa aqui - MDR, ISO 13485, MDSAP e mais pela DQS!

Software em conformidade começa aqui - MDR, ISO 13485, MDSAP e mais pela DQS!

Con­tacte-nos!

Artigos e eventos relevantes

Você pode também estar interessado em
Blog
MED AI in Medical Devices Meeting EU Compliance with AI Act and MDR
Loading...

IA nos dispositivos médicos: Cumprir a conformidade da UE com a Lei da IA e o MDR

Blog
UK PMS 3
Loading...

Regulamentos PMS do Reino Unido para Dispositivos Médicos: Parte 3 - Regulamentos PMS do Reino Unido vs. MDR da UE

Blog
UK PMS 2
Loading...

Regulamentos PMS do Reino Unido para dispositivos médicos: Parte 2 - Requisitos de vigilância e comunicação