O Que Precisa de Saber Antes de Lançar um Dispositivo Médico?

Vamos imaginar o seguinte cenário:

Você criou uma startup para lançar uma aplicação de software de e-Saúde no mercado. Após vários meses de trabalho e pesquisa, finalmente lança a tão esperada aplicação. A sua equipa tem trabalhado incansavelmente no projeto: desenvolveu a ideia, discutiu com profissionais de saúde e desenhou e desenvolveu uma aplicação que será inovador neste setor. Mas para que a sua empresa traga o produto para o mercado europeu, é preciso ter a certeza se o seu produto está totalmente maduro. Poderá ter problemas de conformidade com os regulamentos de dispositivos médicos estabelecidos no novo Regulamento de Dispositivos Médicos (MDR)?
Como startup, iniciou o desenvolvimento em pequenos passos para ver se conseguia fazê-lo, aprender o máximo possível e tentar obter financiamento suficiente. Como é de se esperar de quem está a começar, não tinha experiência suficiente em todas as etapas especificadas nas normas aplicáveis. Então, como pode ter a certeza que cumpre todas as regulamentações e como saber o que precisa de fazer para alcançar o que é realmente necessário para cumprir as mesmas?

Vamos primeiro tentar explicar do que falamos.

Com o novo Regulamento de Dispositivos Médicos (MDR), a Comissão Europeia criou um conjunto de regras que inclui o seu próprio conjunto de definições, classificações e regras para software como dispositivo médico. Para colocar de forma relativamente simples: A classificação de um software como um dispositivo médico depende do seu uso pretendido. Se um fabricante declara uma finalidade médica clara na declaração de finalidade — por exemplo, interpretar os ritmos cardíacos, controlar a depressão sazonal ou aliviar enxaquecas — esse software é considerado um dispositivo médico. O software para propósitos mais gerais de estilo de vida e bem-estar, por outro lado, não o são, a menos que o fabricante faça alegações de publicidade terapêutica ou de diagnóstico.

Por outro lado, se uma aplicação é utilizada para tirar fotos de uma erupção cutânea para ser partilhada com um médico, por exemplo, e apenas armazena essas imagens, não é considerada um dispositivo médico.
Existem cinco classificações de software — Classe I, Im, IIa, IIb e III – com definições específicas para cada uma delas descritas nas Regras 9, 10 e 11. Entender as regras de classificação pode ser bastante complexo, então vamos ilustrar com alguns exemplos de um artigo da Sociedade Profissional de Assuntos Regulatórios de 2019 (RAPS):

“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause death or an irreversible deterioration of a person’s state of health, in which case it is in Class III or a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as Class IIb. Software intended to monitor physiological processes is classified as Class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as Class IIb. All other software is classified as Class I. As an example, software used to monitor heart rates or any other physiological parameters during a routine checkup is classified as Class IIa. However, if the monitoring aims at vital physiological parameters, and where those parameters could result in immediate danger to the patient, the classification is elevated to Class IIb.”

Pode ler mais aqui. 

Voltando ao assunto: O que você e a sua equipa de desenvolvimento de software precisam de melhorar no seu produto e no seu processo de desenvolvimento para implantar um dispositivo médico na Europa?
Para ajudá-lo neste processo, gostaríamos de fazer uma série de perguntas que precisará de responder a si mesmo:

O FABRICANTE

1 – Quem irá colocar o dispositivo médico no mercado? Uma empresa europeia pode lançar um dispositivo médico no mercado, seja software ou não, apenas se estiver registada como fabricante junto da autoridade sanitária nacional do seu país. Em Portugal, por exemplo, onde a LOAD está sediada, este registo é feito pela INFARMED.

2 – Que certificados são necessários? Para obter aprovação regulatória para colocar dispositivos médicos no mercado, os fabricantes de dispositivos médicos devem demonstrar a conformidade técnica e administrativa dos seus produtos com as normas relevantes e obter as certificações necessárias. A certificação mais importante é o Sistema de Gestão da Qualidade ISO 13485 (SGQ).

O PROCESSO

3 – Qual é o processo que a sua equipa seguiu no desenvolvimento do software? Está descrito na ficha técnica que deve acompanhar o seu produto? A norma IEC 62304:2006 descreve os documentos essenciais relacionados ao plano de desenvolvimento, avaliação de risco, requisitos, projeto, implementação, revisão e controlo de versão.

4 – Existe um plano de desenvolvimento de software?

• O plano descreve a classificação de risco conforme a IEC 62304:2006 (A, B ou C)?
• O plano descreve o processo usado no desenvolvimento de software?
• São guardados todos os registros das atividades e tarefas de desenvolvimento?
• Os requisitos implementados no software e as suas medidas de controlo são rastreáveis?
• Existe gestão de controlo de mudanças?

5 – Existe alguma lista documentada de requisitos e avaliação de risco associada a um plano e mapa de avaliação de risco baseada em análise de perigo de software ou métodos FMEA (failure modes, effects and analysis)?

6 – O processo de desenvolvimento de software foi realizado de acordo com uma arquitetura ou design documentado?

7 – Existe alguma matriz de verificação para seguir os requisitos, riscos, verificação e resultados da verificação?

O DESENVOLVIMENTO DE CÓDIGO

8 – Como é feito o backup do software e o controlo das versões? Existe algum sistema/repositório de controlo de versões?

9 – Existe algum processo de revisão documentado de como os bugs detetados são corrigidos e geridos?

10 – Como são geridas as versões do software e quem é responsável por essa gestão?

11 – Para software Classe B, a IEC 62304:2006 requer teste de unidade*. Os testes de unidade foram realizados?

12 – A sua equipa realiza revisões de código a códigos desenvolvidos por terceiros?

Como pode ver, há muitos processos a serem seguidos antes de lançar uma aplicação como um dispositivo médico. Tendo em conta que estamos envolvidos em processos de dispositivos médicos desde 2016, essas são as etapas básicas que a LOAD, certificada com o sistema de gestão de qualidade ISO 13485 e com uma equipa especializada em desenvolvimento de dispositivos médicos, tende a percorrer. A nossa equipa pode ajudar a lançar no mercado o seu software como um dispositivo médico!

Entre em contacto connosco e lance o seu Dispositivo Médico com segurança.

_________________________________________

*O teste de unidade é uma metodologia de teste de software pela qual unidades individuais de código são testadas autonomamente para determinar se elas produzem a saída esperada em relação a uma entrada conhecida. Todas as unidades de software juntas, interagindo entre si, irão compor o sistema. O teste de unidade é, portanto, diferente do teste de sistema, pois este verifica o comportamento de um sistema ou subsistema como um todo.