Software como Dispositivo Médico: Definición y Alcance de las Regulaciones
Publicado: 2019-09-06Desde los últimos 40 años, la cantidad de innovaciones tecnológicas tanto dentro como alrededor de los dispositivos médicos ha aumentado drásticamente. Especialmente, los últimos 20 años han sido testigos de una aceleración en el sector, gracias al Internet de las cosas y al auge de sus otras partes correspondientes, como la conectividad inalámbrica, la computación en la nube, la IA, etc. Estos avances han transformado los procesos de atención médica.
Incluso después de 20 años, estas tecnologías de vanguardia continúan provocando un cambio sísmico en el proceso de administración y prestación de atención médica.
Y ahora, las aplicaciones móviles también se han colado y se han convertido en una parte importante de estos fines médicos y no médicos de base tecnológica tan demandados.
Estas aplicaciones o software que son un dispositivo médico en sí mismos: el tamaño del mercado del software como dispositivo médico ha crecido hasta convertirse en una parte inherente de la vida de los usuarios. Las aplicaciones de SaMD no solo se limitan al diagnóstico, sino que también se han hecho un hueco en el proceso de seguimiento y tratamiento. De hecho, es SaMD el que ha llevado a la evolución de la asistencia sanitaria 1.0 a la asistencia sanitaria 3.0 .
Al ver la creciente inclusión de SaMD en la atención médica diaria, el foro internacional de reguladores de dispositivos médicos (IMDRF), del cual es miembro la FDA de EE. UU., describió el concepto y las categorías de riesgo de SaMD en detalle para que la industria de desarrollo de aplicaciones médicas las siga. El software de la FDA como dispositivo médico ha desarrollado y aclarado políticas basadas en riesgos para una mejor comunicación de los requisitos y alineado su enfoque regulatorio con la naturaleza evolutiva de los dispositivos digitales.
* SaMD no es el único cumplimiento que deben seguir las partes interesadas de la industria de la salud: los empresarios de aplicaciones de mHealth y los fabricantes de dispositivos. También existen otros cumplimientos, como FDA, HIPAA, HL7 y FCPA. Hemos abordado estos cumplimientos con mucho detalle en nuestra En este artículo, vamos a arrojar algo de luz sobre SaMD, el software como regulación de dispositivos médicos y los tipos de aplicaciones mHealth y otros tipos de software médico que se clasifican como software como dispositivo médico.
Tabla de contenidos
- ¿Qué es el software como dispositivo médico?
- ¿Cómo saber si su aplicación móvil es un SaMD?
- Factores a considerar para la caracterización de SaMD
- ¿Cuáles son ejemplos de software como dispositivo médico?
- ¿Cómo se clasifica el software como dispositivo médico?
- ¿Qué pueden hacer los fabricantes de SaMD para garantizar las regulaciones?
- Conclusión
- Preguntas frecuentes sobre SaMD
¿Qué es el software como dispositivo médico?
La terminología: software como dispositivo médico se refiere a cualquier software destinado a uno o varios fines médicos y que realiza estos fines sin estar integrado en un dispositivo médico de hardware.
Así es como IMDRAF define SaMD:
'El término "Software como dispositivo médico" (SaMD) se define como software destinado a ser utilizado para uno o más fines médicos que realizan estos fines sin ser parte de un dispositivo médico de hardware.'
¿Cómo saber si su aplicación móvil es un SaMD?
- SaMD es un dispositivo médico e incluye algunos dispositivos médicos de diagnóstico in vitro (IVD).
- Puede ejecutarse en plataformas informáticas de propósito general (no médicas).
- El software no cumple con la definición de SaMD si su propósito previsto es controlar dispositivos médicos de hardware .
- Puede usarse con otros productos, como dispositivos médicos.
- Puede tener una interfaz con otros dispositivos médicos, incluidos dispositivos médicos de hardware y otro software SaMD, así como software de uso general.
Factores a considerar para la caracterización de SaMD
Hay dos formas en que se caracterizan los SaMD:
Información proporcionada por SaMD
- Para diagnosticar o tratar pacientes.
- Para informar la gestión clínica
- Para impulsar la gestión clínica
Condición de salud
- Condición crítica
- Condición seria
- Condición no grave
Sobre la base de estas caracterizaciones, los SaMD se dividen en cuatro categorías.
¿Cuáles son ejemplos de software como dispositivo médico?
- El software como dispositivo médico se puede interconectar con otros dispositivos médicos, incluidos los dispositivos médicos de hardware y otro software como dispositivo clínico, también como software de uso general. El software que brinda límites se convierte en la entrada para un equipo de hardware diferente u otro SaMD. Por ejemplo, el software como un ejemplo de dispositivo médico puede ser un software de planificación de terapia que aprovisiona los datos utilizados en un acelerador lineal es SaMD.
- Por ejemplo, el software que se espera para el análisis de una condición utilizando el acelerómetro triaxial que funciona en el procesador instalado en una cámara digital de consumo se considera Software como dispositivo médico.
- El software que está conectado con un dispositivo de hardware médico, pero que ese dispositivo no lo requiere para lograr su propósito médico, es un software como un dispositivo médico y no un accesorio del dispositivo médico.
- El software SMD puede ejecutarse en plataformas informáticas de propósito general (es decir, no por razones clínicas). Este software que se ejecuta en estas plataformas informáticas de propósito general podría estar ubicado en un dispositivo médico de hardware.
Categoría Ejemplos sabios de SaMD
Categoría IV:
- SaMD que realizan análisis de imágenes de diagnóstico para permitir decisiones de tratamiento cuando los pacientes sufren un accidente cerebrovascular agudo
- SaMDs que calculan la dimensión fractal de una lesión y construyen un mapa estructural que revela diferentes patrones de crecimiento para brindar diagnóstico o identificar si la lesión es benigna o maligna.
- Los SaMD combinan datos de los inmunoensayos para detectar brotes de patógenos mutables que pueden ser altamente transmisibles.
Categoría III:
- SaMD que utiliza el micrófono del teléfono para detectar la interrupción de la respiración durante el sueño.
- Se utiliza para proporcionar información al hacer clic en imágenes, monitorear el crecimiento u otros datos para complementar otra información que un proveedor de atención médica usa para diagnosticar si una lesión cutánea es benigna o maligna.
Categoría II:
- SaMD que analiza la frecuencia cardíaca.
- SaMD, que utiliza los datos del registro de salud de las personas para predecir los riesgos de enfermedades cardíacas o accidentes cerebrovasculares y crear estrategias de prevención.
- SaMD que integran y analizan múltiples pruebas para ofrecer recomendaciones para el diagnóstico en ciertas indicaciones clínicas.
Categoría I:
- Dispositivos médicos de software que recopilan datos de los diarios de síntomas para proporcionar información para medir la ocurrencia de un episodio de asma.
- Dispositivos médicos de software que analizan imágenes, movimiento del ojo para guiar la siguiente acción de diagnóstico para el astigmatismo.
- Software que almacena información histórica sobre la presión arterial para que la revisen los proveedores de atención médica.
- Software que utiliza datos de sensibilidad auditiva, habla en ruido y pide a los usuarios que respondan cuestionarios sobre situaciones auditivas comunes para la autoevaluación de la pérdida auditiva.
¿Cómo se clasifica el software como dispositivo médico?
El nuevo MDR de la UE (Reglamento de Dispositivos Médicos de la Unión Europea) brinda definiciones, reglas, clasificaciones y requisitos de procedimiento para los estándares de software de dispositivos médicos.
El Anexo VIII de EU MDR habla sobre varios software como reglas de clasificación de dispositivos médicos.
La regla 11 del Anexo VIII se relaciona con la clasificación del software y aborda específicamente la clasificación del software utilizado solo o en combinación con dispositivos médicos.
El software diseñado para proporcionar datos que se utilizan para tomar decisiones en términos de diagnóstico o fines terapéuticos se clasifica en Clase IIa, salvo si tales opciones tienen un efecto que puede causar la muerte o un deterioro irreversible de la salud de un individuo. En tales casos se encuentra en la Clase III o un deterioro grave del estado de salud de una persona o una intervención quirúrgica, en cuyo caso se clasifica en la Clase IIb.
El software que se espera que evalúe procesos fisiológicos se delega como Clase IIa, con la excepción si se propone para observar parámetros fisiológicos esenciales, donde la naturaleza de las variedades de esos parámetros es tal que podría generar una amenaza inmediata para el paciente, en cuyo caso es denominado Clase IIb. El resto del software restante se delega como Clase I.
Por ejemplo, el software utilizado para controlar la frecuencia cardíaca o algunos otros parámetros fisiológicos durante un control de rutina se delega como Clase IIa. Si por casualidad la monitorización se centra en parámetros fisiológicos imperativos, y cuando esos parámetros pudieran suponer un peligro inmediato para el paciente, la clasificación se eleva a Clase IIb.
¿Qué pueden hacer los fabricantes de SaMD para garantizar las regulaciones?
Las empresas SaMD deben tener un buen Sistema de gestión de calidad incorporado en el proceso de desarrollo para garantizar el cumplimiento de cualquier regulación. La plataforma QMS elegida debe ser capaz de cumplir con los requisitos reglamentarios como FDA 21 CFR Parte 820 e ISO 13485:2016.
Cualquier paso en falso en la dirección puede tener graves consecuencias y la prohibición de su aplicación es solo el punto de inflexión. Teniendo en cuenta la importancia, se recomienda que se asocie con una empresa de desarrollo de software de atención médica personalizada que trabaje junto con médicos que comprendan estas regulaciones y el cumplimiento en su totalidad.
Conclusión
Las empresas de desarrollo de aplicaciones para el cuidado de la salud en los EE. UU . que actualmente desarrollan software para usarse en conexión con dispositivos médicos, o como un dispositivo médico independiente, deben estar al tanto de estos cambios y asegurarse de implementar las medidas para garantizar que su software cumpla con el nuevo régimen.
Preguntas frecuentes sobre SaMD
P. ¿Cuáles son ejemplos de software que no son SaMD ?
- Aplicaciones que los dispositivos médicos de hardware necesitan para realizar su función.
- Aplicaciones que dependen de los datos del dispositivo médico.
- Aplicaciones que permiten la comunicación y la agilización del flujo de trabajo clínico, como las de programación de visitas, videollamadas o llamadas de voz, etc.
Los ejemplos de aplicaciones no se limitan a estos. Hay una serie de otros tipos de aplicaciones que no se incluyen en la definición de SaMD.
P. ¿Qué puede hacer realmente el software como dispositivo médico?
Las aplicaciones SaMD son aquellas que actúan como una aplicación de salud independiente que brinda a los usuarios información sobre su salud física al hacer diagnósticos, procesar rayos X o calcular las dosis de insulina.
P. ¿Qué es IEC 62304?
IEC 62304 es un estándar que especifica los requisitos del ciclo de vida necesarios para la creación de software como dispositivo médico y software dentro de los dispositivos médicos. Cuando se usa junto con ISO 13485, ofrece un marco que es importante para el diseño y mantenimiento seguros del software de dispositivos médicos.
P. Describa su proceso QMS para el desarrollo de software de dispositivos médicos
Tenemos nuestro propio SGC interno para trabajar con clientes farmacéuticos y de dispositivos médicos, para garantizar nuestra propia calidad. No somos auditados por clientes, terceros o reguladores.
Etapa 1 : Iniciar el Proyecto: Llevar a cabo una teleconferencia inicial con el Cliente para:
Revisar el plan y el cronograma del proyecto
Finalizar fuentes clave de información
Definir el equipo del proyecto.
Etapa 2 : Revisión de la documentación: evalúe y examine todos los documentos relevantes, incluida la información del producto existente, los datos/planes no clínicos y la documentación reglamentaria. Las fuentes de esta información son:
Datos no clínicos, correspondencia reglamentaria, especificaciones técnicas de productos, referencias a dispositivos predicados, declaraciones de productos propuestos y uso previsto/indicaciones, etc.
Etapa 3 : Determinar el camino regulatorio Utilizando la información de la sección anterior, desarrolle un camino regulatorio de la FDA para determinar si 510(k) o de novo es más apropiado (una estrategia regulatoria de PMA es más compleja y requerirá un presupuesto más alto). El objetivo será asesorar al Cliente sobre el enfoque óptimo para la FDA.