Resposta curta: quando um software tem um propósito médico (diagnóstico, prevenção, monitorização, previsão, prognóstico, tratamento), é considerado um dispositivo médico ao abrigo do Regulamento de Dispositivos Médicos da UE (MDR, 2017/745) e recebe uma classe de risco: I, IIa, IIb ou III, maioritariamente pela Regra 11 do Anexo VIII. A classe determina se pode auto-certificar-se (apenas classe I) ou se necessita de um organismo notificado, a profundidade da avaliação clínica e como funciona a vigilância pós-comercialização. Separadamente, a norma de engenharia IEC 62304 atribui ao software uma classe de segurança: A (nenhum dano possível), B (dano não grave possível) ou C (morte ou dano grave possível), que determina a documentação, o design e os testes que o ciclo de vida exige. As duas classificações estão relacionadas, mas são independentes, e ambas são definidas pelo dano que o software pode causar, não pela sua complexidade.
Passo 1: é um dispositivo?
O software é considerado um dispositivo médico ao abrigo do Regulamento Europeu de Dispositivos Médicos (MDR) quando o seu propósito é médico: diagnóstico, prevenção, monitorização, previsão, prognóstico ou tratamento (Artigo 2(1)). O software que apenas armazena, arquiva, comunica, exibe ou pesquisa dados não é um dispositivo; o software que cria ou modifica informação médica para apoiar uma decisão de diagnóstico ou tratamento é-o, de acordo com o MDCG 2019-11.
A definição do MDR (Artigo 2(1)) foca-se no propósito pretendido. Software que armazena, arquiva, comunica, exibe ou realiza pesquisas simples em dados não é um dispositivo (o MDCG 2019-11 destaca isto). Software que cria ou modifica informação médica para apoiar uma decisão de diagnóstico ou tratamento é. Um registo que mostra um valor de laboratório com o intervalo de referência do laboratório não é; software que informa o utilizador que o valor indica uma condição, ou recomenda uma dose, é. Veja Uma aplicação de saúde é um dispositivo médico? para o passo de qualificação em detalhe.
Passo 2: a classe de risco MDR, Regra 11
A Regra 11 do MDR classifica o software de dispositivo médico com base no dano que uma decisão incorreta poderia causar. O software que fornece informação para decisões de diagnóstico ou terapêuticas é, por defeito, classe IIa; classe IIb se tais decisões puderem causar deterioração grave ou cirurgia; e classe III se puderem causar morte ou deterioração irreversível. O software de monitorização é classe IIa, ou IIb para parâmetros vitais.
| Software destinado a… | Classe MDR |
|---|---|
| fornecer informação usada para tomar decisões com fins de diagnóstico ou terapêuticos (o padrão) | IIa |
| …onde tais decisões possam causar morte ou deterioração irreversível da saúde | III |
| …onde tais decisões possam causar uma deterioração grave da saúde ou uma intervenção cirúrgica | IIb |
| monitorizar processos fisiológicos (o padrão) | IIa |
| …monitorizar parâmetros fisiológicos vitais onde variações possam resultar em perigo imediato para o paciente | IIb |
| qualquer outra coisa (software que é um dispositivo mas nenhum dos anteriores) | I |
A Regra 11 empurrou a maioria do software anteriormente classe I para IIa ou superior, o que é a principal razão pela qual o MDR foi sentido como uma mudança significativa para a saúde digital. O MDCG 2019-11 e o quadro de risco da IMDRF (significância da informação × estado da situação de saúde) ajudam a posicionar casos limítrofes. Software que controla ou influencia um dispositivo de hardware assume a classe desse dispositivo (Regra 3.3 das regras de execução).
Consequências por classe: a classe I é autodeclarada com um dossier técnico e registo, sem organismo notificado (exceto Im, Is, Ir); a IIa necessita de uma avaliação por organismo notificado do sistema de qualidade e uma amostra da documentação técnica; a IIb o mesmo com maior escrutínio da documentação; a III uma revisão completa da documentação técnica e, quando relevante, consulta de painel de especialistas. Todas as classes necessitam de um sistema de gestão de qualidade, avaliação clínica proporcional à classe, uma pessoa responsável pela conformidade regulamentar, UDI, registo na EUDAMED, vigilância pós-comercialização e alerta.
Passo 3: a classe de segurança de software IEC 62304
A classe de segurança de software IEC 62304 avalia o software de dispositivo médico com base no pior dano a que poderia contribuir, após controlos de risco externos: classe A quando não é possível qualquer lesão; classe B quando é possível uma lesão não grave; classe C quando é possível morte ou lesão grave. A classe determina o rigor do processo de conceção, verificação e documentação do ciclo de vida do software.
A IEC 62304 (2006, alterada em 2015) é a norma harmonizada para processos do ciclo de vida de software de dispositivos médicos. A sua classe de segurança deriva da pior situação perigosa à qual o software pode contribuir, após considerar medidas de controlo de risco externas ao software:
| Classe | Situação perigosa pode levar a… | O que o ciclo de vida exige |
|---|---|---|
| A | nenhum dano ou dano à saúde | Plano de desenvolvimento de software, requisitos, lançamento; resolução de problemas; gestão de configuração |
| B | dano não grave | A: mais design arquitetural, verificação de integração e testes de sistema, verificação de unidade documentada |
| C | morte ou dano grave | B: mais design detalhado para cada unidade, segregação arquitetural adicional, verificação mais rigorosa |
As classes são atribuídas por sistema de software e podem ser atribuídas por item de software após decomposição, de modo que apenas as partes de risco carreguem o rigor da classe C; a norma explica o argumento de segregação que isto requer. A ISO 14971 (gestão de risco) alimenta a classificação; a IEC 82304-1 adiciona requisitos a nível de produto para software de saúde que corre em plataformas de uso geral (telefones, nuvem).
Como as duas interagem
A classe de risco do MDR e a classe de segurança IEC 62304 são independentes: a classe do MDR (I a III) decide a via regulamentar e o envolvimento de organismos notificados, enquanto a classe IEC 62304 (A a C) decide o rigor do processo de engenharia. Uma aplicação de classe IIa pode ser de classe 62304 B ou C, dependendo do dano que um resultado incorreto possa causar.
A classe MDR é sobre a via regulamentar; a classe IEC 62304 é sobre o processo de engenharia. Uma aplicação classe IIa ao abrigo da Regra 11 pode ser IEC 62304 classe B (informação incorreta pode levar a um atraso não grave no cuidado) ou classe C (se uma sugestão de dose incorreta puder matar). Um dispositivo classe I é geralmente 62304 classe A, mas não necessariamente. Os organismos notificados esperam que o dossier técnico mostre a classe 62304 com a sua justificação, os documentos do ciclo de vida a esse nível e a ligação ao dossier de gestão de risco. A cibersegurança (MDCG 2019-16, IEC 81001-5-1) é avaliada em conjunto.
Exemplo prático
Um exemplo prático de SaMD: uma aplicação de acompanhamento de sintomas que regista, exibe e partilha sintomas não é um dispositivo médico. Adicionar uma funcionalidade que pontua os sintomas com base numa escala validada e informa o utilizador quando procurar cuidados médicos torna-a um dispositivo, Regra 11 do MDR classe IIa por defeito, com classe IEC 62304 B, ou classe C para um caso de uso cardíaco.
Uma aplicação de rastreio de sintomas que permite aos utilizadores registar sintomas, ver tendências e partilhá-las com o seu médico: não é um dispositivo (armazenamento, exibição, comunicação). A mesma aplicação adiciona uma funcionalidade que pontua os sintomas registados contra uma escala validada e informa o utilizador quando a pontuação sugere que deve procurar cuidados: agora é um dispositivo, classe IIa por defeito da Regra 11 (informação para uma decisão de diagnóstico; um "não é necessário procurar cuidados" incorreto poderia atrasar o tratamento, grave mas não tipicamente irreversível, portanto não IIb ou III a menos que a condição visada o torne assim). IEC 62304: um falso reasseguramento poderia levar a um atraso no cuidado, não grave a grave dependendo da condição, portanto classe B, possivelmente C para um caso de uso cardíaco. Via: ISO 13485 QMS, organismo notificado, avaliação clínica da escala, engenharia de usabilidade (IEC 62366-1), vigilância pós-comercialização.
Os Estados Unidos, brevemente
Nos Estados Unidos, a FDA regula o software como dispositivo médico com base na sua finalidade, com classes I, II e III e as vias 510(k), De Novo e PMA. O 21st Century Cures Act exclui o software administrativo, produtos de bem-estar geral, registos de saúde eletrónicos e certos apoios à decisão clínica do estatuto de dispositivo. A FDA reconhece a IEC 62304 como uma norma de consenso.
A FDA regula software como dispositivo médico sob a mesma lógica de propósito pretendido, com classes I, II e III e vias 510(k), De Novo e PMA. O 21st Century Cures Act (secção 3060) removeu várias categorias do estatuto de dispositivo: software administrativo, bem-estar geral, registos de saúde eletrónicos e suporte de decisão clínica que permite ao médico rever independentemente a base da recomendação (a orientação da FDA de 2022 sobre CDS interpreta isto de forma restrita). A FDA reconhece a IEC 62304 como uma norma de consenso e, desde 2023, exige documentação de cibersegurança para "dispositivos cibernéticos". A ISO 13485 tornou-se a base do regulamento do sistema de qualidade dos EUA (QMSR) em 2026.
Em Anpheros
Anpheros Daily armazena, exibe e partilha; não pontua, interpreta ou recomenda, e o seu propósito pretendido diz isso. Portanto, não é um dispositivo médico ao abrigo da Regra 11 ou das exclusões do Cures Act, e a equipa aplica segurança estilo ISO 27001 e prática de software documentada sem a via de dispositivo. Se alguma vez fosse adicionada uma funcionalidade com propósito médico, seria classificada ao abrigo da Regra 11 e desenvolvida sob a IEC 62304 antes do lançamento. Veja Transparência de saúde.
Esta página explica a regulamentação para equipas de produto e engenharia. Não constitui aconselhamento jurídico; os textos ligados em Fontes são a autoridade, e o seu responsável pela proteção de dados, organismo notificado ou consultor decide para o seu caso. Última revisão: Outubro de 2026.
Páginas relacionadas
- Uma aplicação de saúde é um dispositivo médico? Regra 11 do MDR da UE
- MDR vs IVDR
- CDS Hooks explicado
- Mapa de regulamentação de dados de saúde
- O AI Act da UE e a IA na saúde
Fontes
- Regulamento (UE) 2017/745 (MDR), Anexo VIII, EUR-Lex
- MDCG 2019-11: Qualificação e classificação de software
- IEC 62304:2006+AMD1:2015, Processos do ciclo de vida de software de dispositivos médicos
- IEC 82304-1:2016, Segurança de produtos de software de saúde
- FDA: Orientação sobre Software de Suporte à Decisão Clínica (2022)
- FDA: Software como Dispositivo Médico
Perguntas frequentes
Pode o software ser classe I ao abrigo do MDR?
Sim, mas raramente: apenas software com propósito médico que nem informa decisões de diagnóstico ou terapêuticas nem monitoriza processos fisiológicos. A maioria das aplicações que se qualificam como dispositivos entram na classe IIa.
Um dispositivo classe IIa necessita de ensaios clínicos?
Necessita de uma avaliação clínica, que pode basear-se em literatura, equivalência e dados de desempenho; uma investigação clínica é exigida quando a evidência existente é insuficiente. Software que reivindica desempenho diagnóstico geralmente necessita do seu próprio estudo de desempenho.
A IEC 62304 é obrigatória?
É uma norma harmonizada, pelo que segui-la é a presunção de conformidade com os requisitos de software do MDR (Anexo I, 17). Pode usar outra abordagem, mas terá de provar equivalência, o que ninguém faz na prática.
E as funcionalidades de IA?
Aplicam-se as mesmas regras, mais o EU AI Act: um dispositivo com avaliação por organismo notificado é um sistema de IA de alto risco ao abrigo do Anexo I, com requisitos sobre dados, registo, transparência e supervisão humana avaliados em conjunto com o MDR.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →