Software como Dispositivo Médico: Definição e Escopo dos Regulamentos

Publicados: 2019-09-06

Desde os últimos 40 anos, o número de inovações tecnológicas dentro e ao redor de dispositivos médicos aumentou dramaticamente. Especialmente, os últimos 20 anos testemunharam uma aceleração no setor, graças à Internet das Coisas e à ascensão de suas outras partes correspondentes, como conectividade sem fio, computação em nuvem e IA, etc. Esses avanços transformaram os processos de saúde.

Mesmo depois de 20 anos, essas tecnologias de ponta continuam a gerar uma mudança sísmica no processo de administração e prestação de serviços de saúde.

E agora, os aplicativos móveis também se infiltraram e se tornaram uma parte importante desses propósitos médicos e não médicos altamente exigidos e baseados em tecnologia.

Esses aplicativos ou software que são um dispositivo médico por si só – o tamanho do mercado de software como dispositivo médico cresceu para se tornar uma parte inerente da vida dos usuários. As aplicações da SaMD não se limitam apenas ao diagnóstico, mas também têm seu lugar no processo de monitoramento e tratamento. Na verdade, é a SaMD que levou à evolução dos cuidados de saúde 1.0 para os cuidados de saúde 3.0 .

Need-of-Software-in-Medical-Devices

Vendo a crescente inclusão do SaMD na saúde cotidiana , o fórum internacional de reguladores de dispositivos médicos (IMDRF), do qual o FDA dos EUA é membro, descreveu o conceito e as categorias de risco do SaMD em detalhes para o setor de desenvolvimento de aplicativos médicos seguir. O software FDA como dispositivo médico desenvolveu e esclareceu políticas baseadas em risco para melhor comunicação de requisitos e alinhou sua abordagem regulatória com a natureza evolutiva dos dispositivos digitais.

* SaMD não é a única conformidade que as partes interessadas do setor de saúde – empresários de aplicativos de mHealth e fabricantes de dispositivos devem seguir. Existem também outras conformidades, como FDA, HIPAA, HL7 e FCPA. Abordamos essas conformidades com muitos detalhes em nosso Neste artigo, vamos lançar alguma luz sobre SaMD, software como regulamento de dispositivo médico e tipos de aplicativos mHealth e outros tipos de software médico que são categorizados como Software como Dispositivo Médico.

Índice

  • O que é Software como Dispositivo Médico?
  • Como saber se seu aplicativo móvel é um SaMD?
  • Fatores a serem considerados para caracterização de SaMD
  • Quais são exemplos de software como dispositivo médico?
  • Como você classifica o software como um dispositivo médico?
  • O que os fabricantes de SaMD podem fazer para garantir os regulamentos?
  • Conclusão
  • Perguntas frequentes sobre o SaMD

O que é Software como Dispositivo Médico?

IEC-62304-Framework

A terminologia – Software as a Medical Device refere-se a qualquer software que se destine a ser utilizado para uma ou várias finalidades médicas e que desempenhe essas finalidades sem ser integrado a um dispositivo médico de hardware.

Veja como o IMDRAF define o SaMD –

'O termo 'Software como Dispositivo Médico' (SaMD) é definido como software destinado a ser usado para um ou mais propósitos médicos que executam esses propósitos sem fazer parte de um dispositivo médico de hardware.'

Como saber se seu aplicativo móvel é um SaMD?

  • O SaMD é um dispositivo médico e inclui alguns dispositivos médicos de diagnóstico in vitro (IVD).
  • Ele pode ser executado em plataformas de computação de uso geral (não médicas).
  • O software não atende à definição de SaMD se sua finalidade for conduzir dispositivos médicos de hardware .
  • Pode ser usado com outros produtos, como dispositivos médicos.
  • Ele pode ter interface com outros dispositivos médicos, incluindo dispositivos médicos de hardware e outro software SaMD, bem como software de uso geral.

Fatores a serem considerados para caracterização de SaMD

Existem duas maneiras pelas quais os SaMDs são caracterizados:

Informações fornecidas pelo SMD

  • Para diagnosticar ou tratar pacientes
  • Para informar a gestão clínica
  • Para conduzir a gestão clínica

Condição de Saúde

  • Condição crítica
  • Condição grave
  • Condição não grave

Com base nessas caracterizações, os SaMDs são divididos em quatro categorias.

Quais são exemplos de software como dispositivo médico?

  • O software como dispositivo médico pode ser conectado a outros dispositivos médicos, incluindo dispositivos médicos de hardware e outro software como dispositivo clínico, também como software de uso geral. O software que dá limites torna-se a entrada para um equipamento de hardware diferente ou outro SaMD. Por exemplo, o software como um exemplo de dispositivo médico pode ser um software de planejamento de terapia que fornece dados utilizados em um acelerador linear é SaMD.
  • Por exemplo, o software que é esperado para análise de uma condição utilizando o acelerômetro triaxial que funciona no processador instalado em uma câmera digital de consumidor é visto como Software como Dispositivo Médico.
  • O software que está conectado a um dispositivo de hardware médico, mas não é exigido por esse dispositivo para cumprir sua finalidade médica, é um software como um dispositivo médico e não um acessório do dispositivo médico.
  • O software SMD pode ser executado em plataformas de computação de uso geral (ou seja, motivos não clínicos). Esses softwares executados nessas plataformas de computação de uso geral podem estar localizados em um dispositivo médico de hardware.

Exemplos de categorias de SaMD

SaMD types landscape

Categoria IV:

  • SaMDs que realizam análise de imagem de diagnóstico para permitir decisões de tratamento quando os pacientes sofrem um acidente vascular cerebral agudo
  • SaMDs que calculam a dimensão fractal de uma lesão e constroem um mapa estrutural que revela diferentes padrões de crescimento para fornecer diagnóstico ou identificação se a lesão é benigna ou maligna.
  • Os SaMDs combinam dados dos imunoensaios para rastrear surtos de patógenos mutáveis ​​que podem ser altamente transmissíveis.

Categoria III:

  • SaMD que utiliza o microfone do telefone para detectar a respiração interrompida durante o sono.
  • Ele é usado para fornecer informações clicando em imagens, monitorando o crescimento ou outros dados para complementar outras informações que um profissional de saúde usa para diagnosticar se uma lesão de pele é benigna ou maligna.

Categoria II:

  • SaMDs que analisa a frequência cardíaca.
  • SaMD que usam dados de registros de saúde dos indivíduos para prever os riscos de doenças cardíacas ou derrames e criar estratégias de prevenção.
  • SaMD que integram e analisam múltiplos testes para oferecer recomendações de diagnóstico em determinadas indicações clínicas.

Categoria I:

  • Dispositivos médicos de software que reúnem dados de diários de sintomas para fornecer informações para avaliar a ocorrência de um episódio de asma.
  • Dispositivos médicos de software analisando imagens, movimento do olho para orientar a próxima ação diagnóstica para astigmatismo.
  • Softwares que armazenam informações históricas de pressão arterial para os profissionais de saúde revisarem.
  • Softwares que utilizam dados de sensibilidade auditiva, fala no ruído e solicitam aos usuários que respondam a questionários sobre situações auditivas comuns para autoavaliação da perda auditiva.

Como você classifica o software como um dispositivo médico?

O novo EU MDR (The European Union Medical Device Regulation) fornece definições, regras, classificações e necessidades de procedimentos para padrões de software de dispositivos médicos.

O Anexo VIII do MDR da UE fala sobre vários softwares como regras de classificação de dispositivos médicos.

A regra 11 do Anexo VIII refere-se à classificação de software e aborda especificamente a classificação de software usado sozinho ou em combinação com dispositivos médicos.

Os softwares planejados para fornecer dados que são utilizados para fazer escolhas em termos de diagnóstico ou fins terapêuticos são classificados como Classe IIa, exceto se tais escolhas tiverem um efeito que possa causar a morte ou uma deterioração irreversível da saúde do indivíduo. Nesses casos é da Classe III ou uma grave deterioração do estado de saúde do indivíduo ou uma intervenção cirúrgica, sendo neste caso classificado como Classe IIb.

O software destinado a rastrear processos fisiológicos é delegado como Classe IIa, com exceção se for proposto para observar parâmetros fisiológicos essenciais, onde a natureza das variedades desses parâmetros é tal que pode trazer ameaça imediata ao paciente, caso em que é denominada Classe IIb. Todos os outros softwares restantes são delegados como Classe I.

Por exemplo, o software usado para rastrear frequências cardíacas ou alguns outros parâmetros fisiológicos durante um exame de rotina é delegado como Classe IIa. Se por acaso o monitoramento se concentrar em parâmetros fisiológicos imperativos, e onde esses parâmetros possam trazer um perigo imediato para o paciente, a classificação é elevada para Classe IIb.

O que os fabricantes de SaMD podem fazer para garantir os regulamentos?

As empresas SaMD devem ter um bom Sistema de Gestão da Qualidade incorporado ao processo de desenvolvimento para garantir o cumprimento de qualquer regulamentação. A plataforma de SGQ escolhida deve estar em conformidade com os requisitos regulamentares, como a FDA 21 CFR Parte 820 e a ISO 13485:2016.

Qualquer passo em falso na direção pode levar a consequências graves, com o banimento do seu aplicativo sendo apenas o ponto de inflexão. Observando a importância, é aconselhável que você faça parceria com uma empresa de desenvolvimento de software de assistência médica personalizada que trabalhe ao lado de médicos que entendam esses regulamentos e conformidades em sua totalidade.

Conclusão

As empresas de desenvolvimento de aplicativos de saúde nos EUA que atualmente desenvolvem software para ser usado em conexão com dispositivos médicos, ou como um dispositivo médico autônomo, devem estar cientes dessas mudanças e certificar-se de implementar as medidas para garantir que seu software esteja em conformidade com o novo regime.

Let's Talk

Perguntas frequentes sobre o SaMD

P. Quais são os exemplos de software que não são SaMD ?

  1. Aplicativos que os dispositivos médicos de hardware precisam para desempenhar sua função.
  2. Aplicativos que dependem dos dados do dispositivo médico.
  3. Aplicativos que permitem a comunicação e agilização do fluxo de trabalho clínico, como agendamento de visitas, chamadas de vídeo ou voz, etc.

Os exemplos de aplicativos não se limitam a estes. Existem vários outros tipos de aplicativos que não se enquadram na definição de SaMDs.

P. O que o Software como Dispositivo Médico pode realmente fazer?

Os aplicativos SaMD são aqueles que atuam como um aplicativo de saúde autônomo que fornece aos usuários uma visão sobre sua saúde física fazendo diagnósticos, fazendo processamento de raios X ou calculando doses de insulina.

P. O que é IEC 62304?

IEC 62304 é um padrão que especifica os requisitos de ciclo de vida necessários para a criação de Software como Dispositivo Médico e Software dentro de dispositivos médicos. Quando usado junto com a ISO 13485, oferece uma estrutura importante para o projeto e manutenção seguros de software de dispositivos médicos.

Q. Descreva seu processo de SGQ para desenvolvimento de software de dispositivos médicos

Temos nosso próprio SGQ interno para trabalhar com clientes de dispositivos médicos e farmacêuticos, para garantir nossa própria qualidade. Não somos auditados por clientes, terceiros ou reguladores.

Etapa 1 : Iniciar o Projeto: Realizar uma teleconferência inicial com o Cliente para:

Revise o plano e o cronograma do projeto

Finalize as principais fontes de informação

Defina a equipe do projeto

Etapa 2 : Revisão da documentação: Avalie e examine todos os documentos relevantes, incluindo informações sobre produtos existentes, dados/planos não clínicos e documentação regulatória. As fontes dessas informações são:

Dados não clínicos, correspondência regulatória, especificações técnicas do produto, referências a dispositivos predicados, reivindicações de produto propostas e intenção/indicações de uso, etc.

Etapa 3 : Determinar o caminho regulatório Usando as informações da seção acima, desenvolva um caminho regulatório da FDA determinando se 510(k) ou de novo é o mais apropriado (uma estratégia regulatória de PMA é mais complexa e exigirá um orçamento maior). O objetivo será aconselhar o Cliente sobre a abordagem ideal para a FDA.